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