:: Re: [DNG] New goodies from systemd
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Olaf Meeuwissen
Ημερομηνία:  
Προς: Steve Litt
Υ/ο: dng
Αντικείμενο: Re: [DNG] New goodies from systemd
Hi Steve,

Perhaps a bit late considering the flurry of mails where it looks like
there is actually some work in progress but I did not want to let this
go over my side without a response.

Steve Litt <slitt@???> writes:

> Olaf Meeuwissen said on Sun, 30 Jul 2023 10:24:47 +0900
>
>>> I suggest we form a runit script committee and a sysvinit script
>>> committee, each of which oversees a package of **all** init scripts.
>>
>>Instead of forming committees,
>
> Is the preceding reaction the best way of encouraging participation?


It was a well-meant comment to prevent the kind of bikeshedding you
referred to in your "I offered to help" post[1]. My own experience
with committees is a lot like that, lots of talking, hand waving and
flapping arms with next to nothing getting done.

[1]: https://lists.dyne.org/lurker/message/20230731.124127.695d3cbd.en.html

>>why not contribute to the runit-services
>>and orphan-sysvinit-scripts packages?
>
> 1) Because you give no instructions how to "contribute to the
>    runit-services" package, nor could I easily find it with a web
>    search.


Appologies for not providing any pointers. I had assumed that DNG
regulars, like yourself, would know their way around. Looks like
that was overly optimistic :-(

The most trivial way to contribute to any Debian or Devuan package is
through their respective Bug Tracking Systems (BTS).

https://www.debian.org/Bugs/
https://bugs.devuan.org/

and the links for runit-services and orphan-sysvinit-scripts

https://bugs.debian.org/runit-services
https://bugs.debian.org/orphan-sysvinit-scripts

# Both are not re-packaged by Devuan and taken from Debian as is.

> 2) Because I don't have the time to learn those things but I'd still
>    like to help.


Do yourself a favour: install reportbug and give it a spin.
Sending mail with only two special lines at the top is all that it
takes for a new bug report. Follow-up just needs to be sent to the
bug's mail address. Only takes 15 minutes, tops, to learn the how.

> 3) Because forming a committee in no way subtracts from the
>    runit-services package. I'm pretty sure such a committee would work
>    closely with the runit-services packager.


That's assuming the committee's activities don't take away resources
that could be better spent on actually getting things done.

> 4) Because I found no list of run scripts the runit-services package
>    already has.


See https://packages.debian.org/bookworm/all/runit-services/filelist.
You're looking for the /usr/share/runit/sv/*/run files.

> 5) Because I couldn't do all the testing myself, nor would anyone want
>    all the testing to be done by one person.


The runit-services package maintainer would likely ask whomever reported
a bug to test whatever fix was suggested. Coordination would go through
the bug report.
Hopefully similar for other init systems^W^W service managers.

> 6) Because sometimes a group of individuals working closely has more
>    intelligence than the sum of the intelligences of each individual.
>    And the different people would certainly fill in for the knowledge
>    weakness of each other.


While that is true, those individuals can share their expertise in the
bug reports.

> 7) Because this committee might recruit volunteers who aren't
>    interested in being devs or package managers, thereby growing
>    overall participation.


I'd say pointing folks on this mailing list to the BTS for their
respective choice of service manager package would be good enough.

>> And contact the s6 and openrc maintainer to check how they would like
>> to go about this
>
> As far as s6, why would they care?


I don't know. I don't use s6 but there is an s6 Debian package. If
sysvinit scripts are something that package could benefit from, then
contacting its maintainer seems like the decent thing to do. Ditto
for openrc.

>> ... add to the existing packages or put things in a separate package.
>
> Which is what started this discussion: What do we do when init scripts
> go away. Did you read the post you're replying to?


Yes. As well as all the replies, what went before and all of the
spin-off threads. I don't claim to remember all the nitty-gritty
details of what has been posted though.

As to what we do when init scripts go away (as in: are no longer
included in the packages we install), version control (VC) systems have
an annoying habit to store how things were in the past. Hence, we dig
them out of the package's VC (or upstream's VC if that's were they
originated) and put them back in the most appropriate package, for
starters. Then package maintainers fix whatever bugs are reported, with
the help of folks that care about them.

>> Just a thought.
>
> Is it just me who has perceived that when somebody says "just a
> thought" or "just saying" it's usually sarcastic?


Hoping it's just you :-P
It wasn't sarcastic and perhaps I should have said "Hope this helps"
instead.
# BTW, I don't think "just saying" is the same as "just a thought".
# The former is quite a bit closer to being sarcastic.

> Your reply would have been much more useful if instead of what you
> said, you told me:
>
> * Where we can find the list of completed run scripts?


In the respective packages. Filelists are readily available from
https://packages.debian.org/$package-name, by release and architecture.

> * Where can I find the list of run scripts that have been requested?


> * Who is in charge of the runit-scripts package?


You mean runit-services. See

$ apt-cache show runit-services | grep ^Maintainer:
Maintainer: Lorenzo Puliti <plorenzo@???>

> * Who are the testers?


The maintainer and whomever bothers to test. From personal experience,
the maintainer is pretty good about discussing a fix/patch and asking
reporters to test.

Just a thought,^W^W^W Hope this helps ;-P
--
Olaf Meeuwissen