Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye
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
Reply to: