[Rpm-maint] RPM 4.9.0 alpha available
ffesti at redhat.com
Mon Nov 22 09:43:33 UTC 2010
On 11/22/2010 04:35 AM, Bill Nottingham wrote:
> My pet idea is an informational tag is a tag that defines a package
> as either multilib or not-multilib, for use by distribution compose
> tools for packages to potentially opt-in or opt-out of whatever
> heuristics that such tools use.
From a rpm developers point adding such a tag is not a big deal
(assuming it is well defined and useful). But I doubt that this is
really a good idea. My impression was that the general trend (in Fedora)
is to move distribution policy decisions away from the packager and to a
central point as they typically need deeper insight. That also lets
packager do what they actually best in - building packages - without
caring to much about high level release engineering topics. So putting
information about package lists into the package looks like a move in
the wrong direction.
Also I got the feeling that rebuilding packages is considered painful.
Possibly changing the package list late in the release process is a
thing of it's own but also rebuilding the involved packages (that
already got tested and passed qa) makes it even worse.
But what finally spoils the idea IMHO is the fact that the same set of
packages is used for different spins and products. Even if each spin has
it's own packages list to overwrite the in-package decisions changing a
package may have unwanted and hard to spot implications for the package
list of the spins - like packages (including lots of dependencies)
appearing from nothing or suddenly missing. As there will be the need of
additional lists of exceptions why not stick the multilib packages in
this lists just from the beginning or the PackageDB or some where else?
As my knowledge about release engineering is very I might be wrong or
overestimating these problems. Nevertheless they should be thought
through before we add a tag that might just be unused (and confusing
people) in the end.
More information about the Rpm-maint