On Wed, Oct 05, 2011 at 04:08:31PM +0200, Matthias Klose wrote: > During the oneiric development cycle we had syncs of library packages from > experimental, introducing new sonames, and changing APIs in a way that other > packages need to be ported to the new API, or if the port isn't trivial, need > to > be removed at the end of the cycle. This doesn't add much benefit to the > distribution, compared to the work to clean up the distribution and forward > port > packages which otherwise don't require this kind of work (assuming the package > is synced from Debian). Options to handle such syncs could be > > - Keep the don't care attitude, and just remove packages at > the end of the cycle (although removal of non-leaf packages > comes with a price too, and isn't seen as user friendly). > > - Get approval for a library sync from experimental, listing > the rdepends, API changes, and estimate the effort to > complete this library transition. > > - Don't sync packages from experimental.
- Stage the required reverse-dependency changes in a PPA or similar in advance if at all possible. (I like that option) > There were at least three libraries synced from experimental which required > work > up into the beta phase (I don't have numbers for the "successful" syncs and > merges from experimental): > > - dcmtk, synced from experimental during the end of the natty cycle, > requested MIR (bug 702026). Left alone until the end of the oneiric > cycle, then turned out that the library wasn't even needed. Caused > some grief in bug 779170. Unsure if the sync review would be a help, > because in the end it was uploaded to unstable and the corresponding > debian report is still open (debian 623145). > > - libevent, synced from experimental on 2011-07-08, the sync was > requested in bug 796187. A large number of packages still had > to be converted from libevent1 to libevent2, and finally we > had to package libevent1 to not remove other packages. > Issues were discussed in other distros too: > http://comments.gmane.org/gmane.linux.redhat.fedora.devel/148007 > > - opal, synced on 2011-05-02, with unresolvable build dependencies, > needed another version update and new versions of three packages > during feature freeze (bug 836915). afaics, no discussion for > the sync. libav was a merge from experimental rather than a sync, but it was troublesome too. > All three cases have in common that the packages were left alone for months. > The > third example could have been avoided if we could check build dependencies > when > syncing, and rejecting the sync when the b-d's are not fulfilled (although > there > should be an override option). I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. More discipline for library upgrades would indeed be a good thing. The main problem seems to be library upgrades that don't really have anyone looking after them (and this is worst when it's Ubuntu-local or from Debian experimental; at least in unstable the Debian release team usually cares to some extent). IMO, we should make it clear that if you sync or merge a library from experimental then it is your responsibility to ensure that all reverse-dependencies are ported. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
