On Tue, 02 Feb 2016 13:01:04 +0100, Adam Williamson wrote: > > Even if the spec file uses wildcards to include any shared library > > version, the automatic dependency checks for Rawhide will notice the > > SONAME change and inform the packager about it. > > [...] > > This is too late, though. We don't want to break Rawhide and then find > out after the fact, we want it to not be broken in the first place. That's only due to an artificial limitation imposed by the buildsys and/or the repo compose tool. They could be changed again to keep more than the latest build in the repos. Removing past builds from the repos too early is one of Fedora's weaknesses. The latest upgrade is broken? => People cannot downgrade or roll back unless they have kept any old packages that may be needed for that. And in Rawhide? The latest build can break buildroot creation and image compose tools much too easily, because previous builds are gone already, and depsolvers cannot choose them if needed. > It's actually written down somewhere that packagers are meant to notify > of soname bumps *before* they happen (and similar changes for other > forms of shared libraries) and co-ordinate or do the rebuilds of > dependent packages. That's a work-flow, education and policy issue. A non-wildcard SONAME in a %files list is not enough of a reminder that notifying devel@ list (or preferably the affected packagers directly) is necessary. Plus, the special handling for non-Rawhide builds only causes confusion (such as needing buildroot overrides for non-Rawhide builds whereas Rawhide buildroot is updated directly, and no broken deps check before using bodhi). > In this particular case, this soname bump caused one day's Rawhide > compose to be entirely broken; most images did not build at all. We > want to avoid that. Which is also because the repoclosure run comes too late is is decoupled from the masher. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
