[Rpm-maint] RPM 4.9.0 alpha available

[FlorianFesti]

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.


Florian