[CentOS] Re: pm-utils - ATrpms updates a system package on the stable branch

Axel Thimm Axel.Thimm at ATrpms.net
Wed Jul 9 13:50:58 UTC 2008

On Tue, Jul 08, 2008 at 02:34:01PM -0700, Scott Silva wrote:
> I think a big problem comes when a repo wants to build packageX, but it  
> requires fancywidgetv2.1. But the base system only has fancywidgetv1.9. 
> How would you get packagex without the possibility of breaking something 
> unless fancywidgetv2.1 has backwards compatibility with fancywidgetv1.9?

I completely agree that this is one of the worse situation in
multi-repo land today, let me detail on that:

First of all even if fancywidgetv2.1 were backwards compatible to
fancywidgetv1.9 the promise of no replacemenet cannot be fulfilled,
e.g. the task is to provide the two packages in a way that they don't
remove/break fancywidgetv1.9 in any way.

There are two ways, you either package up fancywidgetv2.1 in a way
that it coinstalls with other versions w/o breaking them. This works
rather well with libraries that had an soname bump. ATrpms packages
these as libfancywidget3-...-...rpm, where 3 is the SONAME.

The other way is to move both out of "stable" and into "testing". Or
to the non-ATrpms speaking folks: Move it out of the repo that
guarantees no replacements and into one that doesn't. That way the
user needs to *consiously* choose to replace a package from base.

Note that in most cases the replacement packages are no worse than the
others. In fact since they usually just turn on a feature or update
the package they are probably even safer than using the less tested
non-replacement packages. But since there are people that disagree
with that opinion and beacuse Open Source is about choice we are
trying hard to please everyone and push the choice to the user.

But the structuring needs to be done at the server side. How would a
yum/smart/etc plugin know that packagex needs fancywidgetv2.1 over
fancywidgetv1.9 unless there is a manual hard requirement in the
package or a soname bump by happenstance?

And wrt manual versioned dependencies, who is really that disciplined
to do that? I have a couple of packages in Fedora requiring say python
>= 2.2 and I was repeatedly asked why I don't drop it -- the
dependencies are known to be there. Less dependencies make the
specfile more readable.

So client side filtering needs a lot of love from packagers and a
rethinking about minimal specfiles and if we do need human resources
to do that, let's do it properly on the server side and keep packaging
styles as they are.
Axel.Thimm at ATrpms.net

More information about the CentOS mailing list