Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Ian Jackson]

Control: close -1

Hi.  I have been asked to take a look at this bug.  I've reviewed the
bug log and tried to identify what the issues are that this bug is
about.

The title is an objection to the Conflicts/Replaces/Provides.

I confess I found the bug log rather diffuse.  Many different people
have contributed a variety of material and it is sometimes difficult
to pin down particular problems.


In terms of actual malfunctions caused by this set of package
relationships, digging through the bugs I found references to
these:

 #934132   Unblock request related to buster, no longer relevant
            but I looked through it to try to understand the
	    underlying issues.

 #935910   "apt: Should be less tolerant of dpkg errors..."
           This is now fixed in apt, in bullseye.

 #934491   The corresponding blocking bug in elogind.  This
           represents the fact that elogind should not migrate
	   to bullseye until #935910 had been fixed or avoided.

#934491 is itself RC.  It seems most convenient to deal with that
separately, in its own bug; so I don't think that is an issue that
should be seen as part of this bug.

#935304 is mentioned, but it is related to the libpam-systemd
dependency and seems not really related to this bug.


The bulk of the bug is a discussion about the general approach to
allowing Debian users to choose between systemd and elogind (and,
therefore, allowing them to run desktoppy kind of software without
systemd).  As discussed it seems that this C/R/P is needed to
implement the approach which was agreed between the elogind and
systemd maintainers.

I think that it is appropriate that, if possible, the approach taken
should be one that is agreeable to both sets of maintainers.  That
makes for the least interpersonal friction (and of course the
respective sets of maintainers are best placed to foresee issues and
judge the merits and (in)elegance of possible approaches).

So my starting point is that it doesn't seem to me to have been
particularly fruitful to reopen this decision via this bug in this
way.  But in any case, the decision has been discussed at some length
here.  It doesn't appear that other options are better.


The submitter was asked to state any specific concerns.  In response:

| So one thing I think we should ensure is we don't end up
| uninstalling systemd without an explicit user choice.

But, the maintainer reports results of experiments, in message #236,
which show that that is already the case.

| So I am not sure any changes are required in order to enforce explicit
| instruction before attempting removal of systemd.
|
| Is this sufficient?

There hasn't been a reply to that.


So I think all of the concrete issues or concerns raised here in this
bug have been either recorded more conveniently in other bugs, or
resolved - whether that resolution was by fixing bugs, or by verifying
that the posited misbehaviour does not occur.

It seems to me therefore that this bug ought to be closed.  Everything
in it has been dealt with, one way or another.

If there are any remaining particular, specific, issues or problems,
it would probably be most convenient if they were filed as individual
bugs.  That would let us get to grips with them properly.

Thanks,
Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.