Re: Bits from the release team (freeze time line)
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.
Reply to: