On 2013-12-26 19:23, Josh Triplett wrote: > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: >> Britney changes >> =============== >> >> We have deployed a change in Britney that causes her to pay more >> attention to essential packages. In particular, all packages now have >> to be co-installable with the essential set. Previously, a package >> could conflict with a essential package. It would still be considered >> installable by Britney as long as the transitive dependency closure of >> the package did not (explicitly) require the essential package it >> conflicted with. > > Here's the complete list of packages in latest unstable that would > violate this new criterion: > > ~$ aptitude search '?conflicts(?essential)' > p systemd-sysv - system and service manager - SysV links > p upstart - event-based init daemon >
We knew that upstart was affected and systemd-sysv does not come as a surprise to me. > This new criterion would seem to make life difficult for the maintainers > of these and other potential future alternatives to the current set of > essential packages. > I do not see how you conclude that it will make life (any more) difficult. Anyhow, I think you might be overly concerned about the downsides of this change compared to the positive side. > In addition to the small mountain of discussion ongoing about init > system defaults, there has also been some discussion on the specific > topic of this conflict (specifially, whether the package named > "sysvinit" should drop the Essential flag, or whether it should become a > metapackage depending on multiple alternative providers of /sbin/init). > The latter discussion unfortunately seems to have been deferred in favor > of the former. > I am well aware of this discussion. If sysvinit were to lose its Essential bit (or we use the metapackage solution), systemd-sysv and upstart would no longer be affected by this change. > Perhaps, in light of the pending tech-ctte decision of doom, it might > make sense to defer enabling this new criterion until at least that > point, to ensure that the maintainers of these two packages can continue > to maintain them and provide upgraded versions? (To the extent other > external factors have not already prevented proper maintenance of those > packages, such as the unmodified packaging of new upstream versions with > useful new features.) > I am not convinced it makes sense to undo this change, in particular ... > Or, will there be a testing migration exception for packages which > already exist in testing, which both of these do? > > - Josh Triplett > > Yes, there are. In general, a package can still migrate to testing as long as it does not increase the total number of uninstallable packages. This is a privilege packages in testing have that sid ones generally do not[1]. Only new reverse dependencies will require manual action (and then, only once). Mind you, such packages are still "second-class" in Britney's eyes, since she will *not* prevent them from becoming "less installable" (e.g. she will happy remove a package they depend etc.). Also note that the change makes Britney handle this situation a lot more consistent and in line with what the end-user sees with APT or dpkg. Packages that have a versioned breaks on an essential package can no longer migrate to testing before the updated version of the essential package. While very rarely, such issues have occurred in the past. ~Niels [1] Because a package in sid would generally add a new "uninstallable" package rather than update an existing one. Though, exceptions can occur with "hijacks" of binary packages - but still. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bc83f9.1020...@thykier.net
