>>>>> "Mark" == Mark Hindley <m...@hindley.org.uk> writes:
Mark> Julian,
Mark> On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote:
>> > I don't think it's reasonable to ship this package with C/R/P >
>> libsystemd0.
>>
>> I understand that you don't like it. However, for libelogind0 to
>> export the same symbols as libsystemd0 so that it could C/R/P
>> libsystemd0 was the agreed solution to bug #923244.
>>
>> Do you have another suggestion as to how we could have resolved
>> that? Other solutions were discounted at the time.
>>
>> > 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.
>>
>> I think it seems likely from discussions on #debian-dpkg that
>> #935910 will be fixed in APT and #934491 can be addressed by
>> adding Breaks: << fixed APT.
Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that
Mark> installed I can no longer reproduce #934491. The APT
Mark> maintainers have said that adding a Breaks for the fixed
Mark> version of apt is not useful.
Normally in a situation like this we would wait until the next stable
release for depending on the change in apt.
It's a bit complicated because it is a bug, but Julian's idea that we
need to wait until bullseye+1 to depend on this apt fix is not an
unreasonable approach.
Mark> I have tried the approach suggested by Laurent of using
Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs
Mark> to function correctly.
What trouble did you run into?
Mark> Are there any outstanding issues that you would like me to
Mark> address to resolve this bug?
So, I think I understand Julian's issues better after trying to write my
bits from the DPL mail.
You haven't really tried to address them at all.
His issue is that we have a long history of trouble with apt and c/r/p
being used this deep in the dependency chain.
So, he's arguing that you have a high bar (possibly infinitely high) for
using that approach.
Ultimately he wants you to produce a solution where multiple init
systems can be coinstalled and where you don't need a conflicts.
I think you've explored some of that design space and have a feel for
why some of that is unattractive.
As an example, if you have systemd installed, it might be running. The
combination of systemd running and libelogind0 being the systemd library
is unfortunate. Trying to boot systemd in that configuration (using
libelogind0) would presumably be quite fatal.
So, the next question is why libelogind0 needs to exist. That is why
can't you just use libsystemd0 with elogind?
What I've heard so far is "It doesn't work."
Why doesn't it work? How hard would it be to make it work?
Would that be better for Debian than using c/r/p?
And the answer to some of these might be "we don't know and we don't
have anyone who can find out."
That is a fine answer to give, although it might also be fine for the
release team to say that they want that analysis before committing to
something dangerous like c/r/p libsystemd0.
But even if we understand why libelogind0 is needed, then why do we need
c/r/p libsystemd0?
Could we do something with dpkg-divert? Would that be better?
If we are going to use c/r/p libsystemd0, is there some way we can limit
the potential damage to people who have positively indicated that they
want to run a non-default init system?
One of the concerns is what happens if apt decides somehow that it wants
to install libelogind0 when you don't expect it.
It might be better to have some init-chooser app where you had to
explicitly decide you wanted to opt into a non-default init before it
was possible to get into a situation where libsystemd0 was provided by
libelogind0.
I don't see how to make that work; I'm just brainstorming.
I think it is reasonable for you to expect Julien to be constructively
engaged in the discussion, to find someone else who will constructively
engage and take ownership of his position, or for the bug to close. At
one level Julien is frustrated: you haven't been addressing his core
issue of the design choice to use c/r/p libsystemd0 and to not have
multiple inits coinstallable. But at another level Julien has stalled
your project for multiple months, and if we're going to do that we need
to be prepared to engage in trying to actually solve the problem. I
think some of the frustration here may stem from you not knowing how to
respond to his issue. You don't have a design without c/r/p libsystemd0
that meets your needs. And so you've been focusing on trying to solve
the things you could, hoping that would be enough. Where as a great way
to engage with an issue like this is to explain why Julien is asking you
to do something hard and ask him to work with you to find a solution
that meets your constraints and his.
And yeah, I understand that it's frustrating to have had this discussion
with systemd maintainers and then turn around and need to have it with a
release team member.
And I did try to read the systemd discussions. If you had clearly
articulated in that discussion why you needed c/r/p libsystemd0 at a
level deeper than "because it doesn't work the other way," then I'd be
pushing back on Julien harder.
--Sam
