On Tue, Sep 3, 2019 at 15:29:49 +0100, Mark Hindley wrote: > On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote: > > I think your summary is fine. However, this is not my area of expertise and > > I'm rather hoping Julien or Ansgar will chime in with an update. > > > > It certainly wouldn't be appropriate for me to remove a block put in place > > by someone else without extenuating circumstances. > > Julien, > > I am still waiting for some constructive engagement over this. > > As Jonathan's comment above makes clear and is echoed by this exchange on > #debian-release yesterday: > > <LeePen> Hello. #934132 is still outstanding and is now preventing resolution > of RC bug in bullseye #939101. [12:13] > <LeePen> Can we find a resolution to #934132? Thanks. [12:17] > <h01ger> weasel: zwiebelbot is missing here [12:34] > <jmw> jcristau: ^ (#934132) [13:12] > <jcristau> jmw: well i still think shipping this thing is a bad idea. but i'm > ok with somebody else removing the block. [13:21] > <jmw> I don't know enough about it to make a call on that > <jmw> but I think LeePen would appreciate some sort of response > > it is obvious and completely understandable that other members of the Release > Team will not overrule your hint blocking elogind migration to bullseye. So, > resolution of this bug (and the resulting FTBFS in bullseye) is down to you. > > I have tried to answer your concerns in detail. If you think my answers are > inadequate or still think there are issues that need to be addressed, please > specify them. If not, please remove your block of elogind's migration to > testing. > I don't think it's reasonable to ship this package with C/R/P libsystemd0.
I think it opens you (and, more importantly, users) up to issues like #934491. Even if #935910 were to be fixed in the package manager in bullseye, it would still mean libelogind0 couldn't ship with the C/R/P until bullseye+1. But beyond that particular issue, I'm sorry to say I think fundamentally attempting to provide a drop-in replacement for libsystemd0 while conflicting with systemd is doomed. The replacement of sysvinit with systemd was careful to keep both init systems co-installable, and I think that's something to preserve to avoid providing users with a loaded footgun with alternative init systems. Anyway, I guess if #934491 is upgraded to RC then I can drop the block hint. Cheers, Julien
