On Fri, 5 Jul 2019 20:35:45 +0200 viverna <[email protected]> wrote:
> il devuanizzato Steve Litt <[email protected]> il 04-07-19 > 22:23:51 ha scritto: > >Hi viverna, > > > >I have a very different viewpoint than most people, so the following > >is *my opinion* and is not in the mainstream. > > > >I think that, for both s6 and runit, run scripts (and any finish > >scripts or environment files) should come from a small committee of > >runit/s6 experts, NOT from the overworked "upstreams" who created the > >software, nor the overworked distro-based maintainers who adapt the > >software to the distro. During the Debian-User systemd war, one of > >the greatest sources of resistance to multi-initism was "upstreams" > >and maintainers who bitched about now having to take care of an > >extra set of init scripts. > > > >If each "upstream" simply documents: > > > >1) How to run the software, in the foreground, without excessive > > logging. > >2) The preferred user and group to run the software. > >3) What daemons should already be running before the software. > >4) Any special state circumstances necessary to start the software. > >For > > instance: > > * Network up > > * Such and such file with so and so permissions > > * Etc. > >5) Any cleanup that must be done after the software finishes or > >crashes. 6) Any environment vars the software is responsive to. > >7) The software's response to any signals. > >8) Any special logging the software does all by itself. > >9) Does it require a "twin" daemon, like smbd and nmbd, and if so, > > which should start first? > > > >Possessing the preceding info, it's easy to make an s6 or runit run > >script, finish script, and if necessary environment file. In most > >cases only the first 4 are really necessary. If an "upstream" > >refuses to answer the questions, the info can probably be gleaned > >from the software's systemd unit file. > > > >This list of questions could be sent to each "upstream", and the > >answers will almost 1 for 1 correspond to the run script. > > > >The runit package could install tree /etc/runit/scriptdirs and the > >directory /etc/sv, and a daemon's (call it mydaemon) install could > >include something like the following: > > > >if -d /etc/runit/scriptdirs; then > > ln -s /etc/runit/scriptdirs/mydaemon /etc/sv/mydaemon > >fi > > > >Uninstalling the mydaemon package would remove > >symlink /etc/sv/mydaemon. > > > >My method runs counter to the way it's always been done, and I always > >get a lot of pushback when suggesting it, but my way would probably > >limit resistance from "upstreams" and maintainers, and would not > >require those people to become runit and/or s6 experts. Meanwhile, it > >would be trivial for a couple runit and s6 experts to write the > >actual startup files, based on the "upstream"s answer to a few simple > >questions. > > > >SteveT > > > >Steve Litt > >July 2019 featured book: Troubleshooting Techniques > > of the Successful Technologist > >http://www.troubleshooters.com/techniques > >_______________________________________________ > >Dng mailing list > >[email protected] > >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > Sounds like a good solution to me, however the main problem remains; > all packaged daemon must implement (at install phase) the simple > script you specified above. > How to do? Devuan, if I'm not wrong, get packages from Debian for all > packages with no systemd hard dependency. > Devuan is a great distro and has excellent developers but limited > manpower. I see what you mean. > I think that fork all daemon is not praticable. Now I see what you're saying. You're probably right. > Instead it's possible > inject in all daemon's install a piece of posix shell? > Workaround script on event "DPkg::Post-Invoke" as I said in the > previous email? You know much more than I do about packaging. Given something like event "DPkg::Post-Invoke", all it would need to do is call a shellscript, with the argument of the daemon name, and the shellscript could make the necessary symlinks or whatever. All the heavy lifting would still be done in the runit-runscripts package. > Else is better another strategy? Maybe just put *all* the daemons in /etc/sv, whether those daemons are installed or not. A diagnostic shellscript could pre-test something in /etc/sv to see if everything needed is installed. > These are questions that I ask myself but it's important for the > future of Devuan and init systems diversity. > The choice of Debian is to follow freedesktop "fancy" guy. A lot of distros have followed that shiny object. > It is not > difficult to think of the day when Debian will remove completely > sysvinit script in all packages. Pre-Cisely! SteveT Steve Litt July 2019 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
