Re: Debian Buster release to partially drop non-systemd support
On Mon, 15 Oct 2018, Jonathan Dowland wrote:
> [ re-adding TG who requested CCs in an earlier message, but has not
> set Mail-Followup-To:. You've probably missed half the conversation,
> Thorsten… ]
Thanks… will follow up on those I read up on in the web interface
(why is there no NNTP interface like in GMane, where I could retrieve
individual messages by Message-ID to easier reply to?) below.
I think we can drop d-backports now, though?
> Is it worth interested parties reaching out to the Devuan project
> regarding person-power for sysvinit maintenance? As a derivative
I’m not sure, but I’d rather not, as a general case, unless there’s
one or more of theirs who’s willing to cooperate and able to keep
quality. Devuan is… questionable, when one’s used to all of Debian.
> distribution, I imagine their lives would become much harder if we did
> drop sysvinit; they would have to pay the cost of maintaining the
Several people have said they believe that to be the end of Devuan,
and I concur, from what I’ve read.
> sysvinit package themselves (which is what I am proposing they do now)
> *as well* as a rapidly growing delta of sysvinit-support/initscripts in
Indeed.
> lots of other packages, as they steadily rotted in Debian.
This takes distributed manpower. Maintainers do not use all packages.
Bugs are spotted by people actually using them (though, if they can
be reproduced easily, can then be tackled by others). My uses are
probably not very normal, though…
Adam Borowski wrote:
>On Mon, Oct 15, 2018 at 08:46:31AM +0200, Laurent Bigonville wrote:
>> Thorsten Glaser wrote:
>> > On Sun, 14 Oct 2018, Andreas Henriksson wrote:
>> >
>> > > Please note that sysvinit dependencies still have open RC bugs which
>> > > noone is caring for.
>> >
>> > Oof. How do I find them out? The BTS shows no RC bugs, not even
>> > ones tagged as affects src:sysvinit, and the QA page
>> > https://packages.qa.debian.org/s/sysvinit.html also doesn’t.
>> insserv
Hmm. This does not answer the question, while it does point out one
package. I’d rather sysvinit not depend on insserv, it used to work
fine without that kind of added complexity, and AIUI, it was only
used for parallel boots (I have /etc/init.d/.legacy-bootordering on
all systems so I don’t use that anyway), and boot speed fetishists
have largely migrated to systemd (which *does* boot up rather fast,
even if its shutdown procedures are…).
Does anyone know any offhand reason to not drop the insserv integration?
>> has 3 RC bugs (6 if you count duplicates) last upload is from 2016
>> by Martin (who is/was systemd maintainer) and is RFA since around that time
>> as well.
>
>These RC bugs are on an experimental abandoned version; the one meant for
>buster is ok.
Can you please RM the experimental version and close those bugs, if
that version is abandoned, since you seem to know more about this?
What does “meant for buster is ok” mean? It’s a bug that needs action
in sid?
Matthew Vernon wrote:
>I'm aware of some work ongoing at the moment to try and improve matters
>(currently looking at elongind, for example). If anyone's got some
What’s elongind? elogind? Never heard of it…
>interest/effort in getting sysvinit (and related bits) in a better state
>for buster, do drop me a line.
I’ve volunteered to help out earlier in the thread, within constraints
(but rather that than to see things go and break).
Thanks,
//mirabilos
--
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general
Reply to: