Re: [DNG] Packages aren't the only path to alternate inits
Has anyone taken a look at pleaserun? Link: https://github.com/jordansissel/pleaserun. It's made by the same person who wrote fpm (Jordan Sissel). It lets you generate init scripts for a plethora of different inits, given only the installed location of the binary. -Jude On Thu, Jun 25, 2015 at 7:50 PM, Florian wrote: > On Thu, 18 Jun 2015 16:58:59 +0200 > Mat wrote: > > > > So in general I think that this approach - moving init system specific > > things out of the main package and providing one package per init > > system > > - is a good way of supporting multiple init systems. > > > > For instance: > > openssh-server - the ssh daemon, stripped of its startup > > script openssh-server-sysv- the traditional sysvinit startup > > scripts openssh-server-run - startup scripts for runit > > openssh-server-epoch - startup scripts for epoch > > openssh-server-openrc - startup scripts for OpenRC > > openssh-server-systemd - why not? > > etc.. > > > Hello diversity! > > It's quite for a while that I'm reading this formidable list, now it's > time to spend my actual two cents: Since I've read the following mail > from the "epoch feature request" thread... > > On Wed, 17 Jun 2015 11:25:28 -0400 > Steve Litt wrote: > > > Here is the sum and total of information that could ever be needed for > > an Epoch Object (service, thing, whatever): > > > (...) > > > > Most of the preceding can safely be left to its default and remain > > unmentioned. Some of it is defined by the LSB header. My point is, by > > the time all is said and done, an Epoch object is pretty darn simple, > > pretty much like a systemd unit file (which is probably what we > > *should* kidnap as our source of conversion data). > > > ...I wonder, if it is necessary to create that many (daemon*initsys) > packages, as Mat (and others?) proposed - or if it was possible to > create some standardized per-daemon config file, to be parsed by > init-system-specific scripts into suitable configurations / init- > scripts. > > On the long run, these "universal" definitions could be maintained with > their respective daemon, while the particular parser-scripts might > become part of the init-systems, possibly as an extra package. > > This should provide a simple way of solving package dependencies, while > bringing greatest flexibility, if these init-system-specific scripts > were invokable in some interactive mode, asking the user (or a higher- > level configuration tool) which daemons to take care of. > > Disclaimer: I'm more of an advanced user than a developer, but willing > to get my hands dirty if this idea should prove to make sense for at > least a subset of the existing (and upcoming:) init-systems, perhaps > even including systemd. > > Regards, > > Florian > > > -- > "A specialist is a barbarian whose ignorance is not well-rounded." > Stanislaw Lem, His master's voice > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 16:58:59 +0200 Mat wrote: > So in general I think that this approach - moving init system specific > things out of the main package and providing one package per init > system > - is a good way of supporting multiple init systems. > > For instance: > openssh-server - the ssh daemon, stripped of its startup > script openssh-server-sysv- the traditional sysvinit startup > scripts openssh-server-run - startup scripts for runit > openssh-server-epoch - startup scripts for epoch > openssh-server-openrc - startup scripts for OpenRC > openssh-server-systemd - why not? > etc.. Hello diversity! It's quite for a while that I'm reading this formidable list, now it's time to spend my actual two cents: Since I've read the following mail from the "epoch feature request" thread... On Wed, 17 Jun 2015 11:25:28 -0400 Steve Litt wrote: > Here is the sum and total of information that could ever be needed for > an Epoch Object (service, thing, whatever): > (...) > > Most of the preceding can safely be left to its default and remain > unmentioned. Some of it is defined by the LSB header. My point is, by > the time all is said and done, an Epoch object is pretty darn simple, > pretty much like a systemd unit file (which is probably what we > *should* kidnap as our source of conversion data). ...I wonder, if it is necessary to create that many (daemon*initsys) packages, as Mat (and others?) proposed - or if it was possible to create some standardized per-daemon config file, to be parsed by init-system-specific scripts into suitable configurations / init- scripts. On the long run, these "universal" definitions could be maintained with their respective daemon, while the particular parser-scripts might become part of the init-systems, possibly as an extra package. This should provide a simple way of solving package dependencies, while bringing greatest flexibility, if these init-system-specific scripts were invokable in some interactive mode, asking the user (or a higher- level configuration tool) which daemons to take care of. Disclaimer: I'm more of an advanced user than a developer, but willing to get my hands dirty if this idea should prove to make sense for at least a subset of the existing (and upcoming:) init-systems, perhaps even including systemd. Regards, Florian -- "A specialist is a barbarian whose ignorance is not well-rounded." Stanislaw Lem, His master's voice signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 13:47, Didier Kryn wrote: > > [...] > >> I wonder if now is the time to start separating out the init specific >> configuration files, initscripts or service files, libraries and >> binaries out into separate packages so that any particular init can be >> supported without treading on the toes of others. The only issue I >> can see with this is the dependency chain can get a bit hairy. >> >> I expect the dependency chain should be something like: >> depends on: init, -sysv-init | -epoch-init | >> -systemd-init | -openrc-init | -upstart-init >> >> And if each of those -*-init packages depended on their >> respective init system, and each of those init systems provide the >> virtual package "init" (as is the case in Debian and Devuan Jessie), >> then apt should be able to work out that when installing that >> because sysvinit-core is the package providing init that it must also >> install -sysv-init in order to satisfy the dependency. The >> problem is whether changing init systems would result in pulling in >> the new -*-init dependency required for the new init system. >> >> Thoughts?? >> > > This is the normal way of implementing this kind of multiple > alternative dependencies in Debian, AFAIU. The only reason I did not > advocate this before is that it would bring in a bunch of new packages > each containing only one small file. But this might not be a big deal > after all, considering it solves the problem completely, allows to get > rid of the irritating systemd service files, and treats all other init > systems equally. > > I support this idea. > Didier I've been using something similar with runit for years: one debian package for each service that contains only the run scripts, some dependency statements, and compatibility scripts for a clean integration with debian (essentially dropping replacement for traditional sysvinit scripts in /etc/init.d/). I generally use sysvinit+runit on servers, but recently I started еxperimenting with runit as init replacement and it's been a smooth ride so far. I've got packages for that as well but they've not really been tested much (not on production servers). My packages were meant only for my personal use but I'm slowly cleaning up the whole thing and putting it online so it could be useful to other people (pushed by the systemd cabale): git sources: http://parad0x.org/git/debian-run/ apt repository: http://parad0x.org/apt/ So in general I think that this approach - moving init system specific things out of the main package and providing one package per init system - is a good way of supporting multiple init systems. For instance: openssh-server - the ssh daemon, stripped of its startup script openssh-server-sysv- the traditional sysvinit startup scripts openssh-server-run - startup scripts for runit openssh-server-epoch - startup scripts for epoch openssh-server-openrc - startup scripts for OpenRC openssh-server-systemd - why not? etc.. It isn't so much work really if it's done in a systematic way. Most of the work went in the postinst/prerm scripts to stop/start the service, and remove/restore the traditional sysv init file: things that wouldn't be necessary if the service package was stripped of the sysv scripts. I know that supporting multiple init systems isn't on the priority list for devuan, but in the longer term I think it would be a nice feature. -- Mat -- Mat signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 22/06/15 23:58, Daniel Reurich wrote: On 20/06/15 05:14, Hendrik Boom wrote: On Thu, Jun 18, 2015 at 09:29:36PM +1200, Daniel Reurich wrote: I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virtual package "init" (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing that because sysvinit-core is the package providing init that it must also install -sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new -*-init dependency required for the new init system. Thoughts?? If you're happily running with epoch, and you install a daemon that happens not to have an epoch init package yet, the only way to resold the matter might be for aptitude to switch your entire machine over to sysv-init because it does have a sysv init package. Or worse, It might find a systemd init script :( That is likely not what you want. You might want the opportunity to cook your own epoch init script, packaged or not. Depending on `a|b|c` doesn't imply an exclusive or, just or, so I'd expect that provided the dependencies for a and c are met, both a and c will be installed unless either those packages or their dependencies would declare an explicit Breaks or Conflicts against each other which makes co-installation impossible. Thinking the dependency graph through a bit further though to allow the side by side installations of init systems, this can be achieved: - Provided no dependency conflicts, we'd either need a symlink or possibly hard link to link /sbin/init to the default init program - so this should probably be provided by a package - lets say init-default- which should declare a Breaks with all the other init-default- packages. - Each respective init system core package should recommend their own respective init-default but not depend on it. Of course to complete the set each init-default- should depend on the package containing the actual init binary. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 20/06/15 05:14, Hendrik Boom wrote: On Thu, Jun 18, 2015 at 09:29:36PM +1200, Daniel Reurich wrote: I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virtual package "init" (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing that because sysvinit-core is the package providing init that it must also install -sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new -*-init dependency required for the new init system. Thoughts?? If you're happily running with epoch, and you install a daemon that happens not to have an epoch init package yet, the only way to resold the matter might be for aptitude to switch your entire machine over to sysv-init because it does have a sysv init package. Or worse, It might find a systemd init script :( That is likely not what you want. You might want the opportunity to cook your own epoch init script, packaged or not. Depending on `a|b|c` doesn't imply an exclusive or, just or, so I'd expect that provided the dependencies for a and c are met, both a and c will be installed unless either those packages or their dependencies would declare an explicit Breaks or Conflicts against each other which makes co-installation impossible. Thinking the dependency graph through a bit further though to allow the side by side installations of init systems, this can be achieved: - Provided no dependency conflicts, we'd either need a symlink or possibly hard link to link /sbin/init to the default init program - so this should probably be provided by a package - lets say init-default- which should declare a Breaks with all the other init-default- packages. - Each respective init system core package should recommend their own respective init-default but not depend on it. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 20.06.2015 11:38, Riccardo Boninsegna wrote: On Fri, Jun 19, 2015 at 11:33 PM, Didier Kryn wrote: Le 18/06/2015 17:23, Laurent Bercot a écrit : Absolutely. Why enforce exclusion when you can have a choice ? Make a "currently active" vs. "inactive" switch, I don't know the Debian/Devuan terminology, and allow users to install both. There's already an exemple of that kind: you may have xdm, gdm3, kdm and lightdm installed; you decide which is the one in effect by running dpkg-reconfigure any-of-them. Yup, assuming the kernel-to-init code understands chained symlinks it would be relatively easy to port all init systems to the "alternatives" feature : The generic name is not a direct symbolic link to the selected alternative. Instead, it is a symbolic link to a name in the alternatives directory, which in turn is a symbolic link to the actual file referenced. Perhaps alternatives are not designed for this, it seems like bad idea for reliability. There are always dangling, casual, insane symlinks in /etc/alternatives for one reason or another. They don't affect trustworthiness only because there are nothing critical here. -- sa ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Laurent: > On 2015-06-20 11:56, k...@aspodata.se wrote: > > # grep /boot/init.sysvinit /var/log/all.log > > Jun 20 11:33:47 opal kernel: [0.00] Kernel command line: > > BOOT_IMAGE=312 ro root=901 noinitrd init=/boot/init.sysvinit > > Jun 20 11:33:47 opal kernel: [2.332734] Failed to execute > > /boot/init.sysvinit. Attempting defaults... > > # ls -l /boot/init.sysvinit > > lrwxrwxrwx 1 root root 12 Jun 20 11:30 /boot/init.sysvinit -> ../sbin/init > > Was /boot on the same filesystem as / ? > My machines (kernels 3.10.62 and 3.19.1) boot on /etc/init which > is a symbolic link, and it's never been a problem. Well spotted, it seems to work perfectly well: # cat /proc/cmdline BOOT_IMAGE=312 ro root=901 noinitrd # ls -l /sbin/init* /etc/alternatives/init lrwxrwxrwx 1 root root24 Jun 20 13:06 /etc/alternatives/init -> ../../sbin/init.sysvinit lrwxrwxrwx 1 root root24 Jun 20 13:06 /sbin/init -> ../etc/alternatives/init -rwxr-xr-x 1 root root 35216 Jul 18 2013 /sbin/init.sysvinit # Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 2015-06-20 11:56, k...@aspodata.se wrote: # grep /boot/init.sysvinit /var/log/all.log Jun 20 11:33:47 opal kernel: [0.00] Kernel command line: BOOT_IMAGE=312 ro root=901 noinitrd init=/boot/init.sysvinit Jun 20 11:33:47 opal kernel: [2.332734] Failed to execute /boot/init.sysvinit. Attempting defaults... # ls -l /boot/init.sysvinit lrwxrwxrwx 1 root root 12 Jun 20 11:30 /boot/init.sysvinit -> ../sbin/init Was /boot on the same filesystem as / ? My machines (kernels 3.10.62 and 3.19.1) boot on /etc/init which is a symbolic link, and it's never been a problem. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Riccardo Boninsegna: > On Fri, Jun 19, 2015 at 11:33 PM, Didier Kryn wrote: ... > Yup, assuming the kernel-to-init code understands chained symlinks it > would be relatively easy to port all init systems to the "alternatives" > feature : ... I doesn't: # grep /boot/init.sysvinit /var/log/all.log Jun 20 11:33:47 opal kernel: [0.00] Kernel command line: BOOT_IMAGE=312 ro root=901 noinitrd init=/boot/init.sysvinit Jun 20 11:33:47 opal kernel: [2.332734] Failed to execute /boot/init.sysvinit. Attempting defaults... # ls -l /boot/init.sysvinit lrwxrwxrwx 1 root root 12 Jun 20 11:30 /boot/init.sysvinit -> ../sbin/init # Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Fri, Jun 19, 2015 at 11:33 PM, Didier Kryn wrote: > Le 18/06/2015 17:23, Laurent Bercot a écrit : >> Absolutely. Why enforce exclusion when you can have a choice ? >> Make a "currently active" vs. "inactive" switch, I don't know the >> Debian/Devuan terminology, and allow users to install both. > > > There's already an exemple of that kind: you may have xdm, gdm3, kdm and > lightdm installed; you decide which is the one in effect by running > dpkg-reconfigure any-of-them. Yup, assuming the kernel-to-init code understands chained symlinks it would be relatively easy to port all init systems to the "alternatives" feature : The generic name is not a direct symbolic link to the selected alternative. Instead, it is a symbolic link to a name in the alternatives directory, which in turn is a symbolic link to the actual file referenced. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Le 18/06/2015 17:23, Laurent Bercot a écrit : Bow, since its possible to have seeral init systems installedd, and even to have different subsytems started by different init systems (not all running as PID 1, of course), perhaps the mutual exclusion among the init systems is a bad idea. Absolutely. Why enforce exclusion when you can have a choice ? Make a "currently active" vs. "inactive" switch, I don't know the Debian/Devuan terminology, and allow users to install both. There's already an exemple of that kind: you may have xdm, gdm3, kdm and lightdm installed; you decide which is the one in effect by running dpkg-reconfigure any-of-them. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 09:29:36PM +1200, Daniel Reurich wrote: > > I expect the dependency chain should be something like: > depends on: init, -sysv-init | -epoch-init > | -systemd-init | -openrc-init | > -upstart-init > > And if each of those -*-init packages depended on their > respective init system, and each of those init systems provide the > virtual package "init" (as is the case in Debian and Devuan Jessie), > then apt should be able to work out that when installing > that because sysvinit-core is the package providing init that it > must also install -sysv-init in order to satisfy the > dependency. The problem is whether changing init systems would > result in pulling in the new -*-init dependency required for > the new init system. > > Thoughts?? If you're happily running with epoch, and you install a daemon that happens not to have an epoch init package yet, the only way to resold the matter might be for aptitude to switch your entire machine over to sysv-init because it does have a sysv init package. Or worse, It might find a systemd init script :( That is likely not what you want. You might want the opportunity to cook your own epoch init script, packaged or not. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 09:47:21AM -0400, Steve Litt wrote: > On Thu, 18 Jun 2015 21:29:36 +1200 > Daniel Reurich wrote: [snip] > > And if each of those -*-init packages depended on their > > respective init system, and each of those init systems provide the > > virtual package "init" (as is the case in Debian and Devuan Jessie), > > then apt should be able to work out that when installing > > that because sysvinit-core is the package providing init that it must > > also install -sysv-init in order to satisfy the dependency. > > The problem is whether changing init systems would result in pulling > > in the new -*-init dependency required for the new init > > system. > > > > Thoughts?? > > My thought is there are some packaging tasks better done by a five step > README doc. All this package dependency described in this email is an > example. Instead, just have one package that installs Epoch, with the > epoch program in /sbin. Have another package that puts common > Epoch daemon defs in a directory, ready for copying and pasting. Just > because one installs Epoch doesn't mean he wants to blow off sysvinit. > One more thing: There are *huge* benefits of being able to choose your > init, at runtime, just by changing your Grub or LILO init= value. I agree on that last point; booting with init=/bin/sh has helped me fix a system more than once. Also, it can be handy to switch between a known-good init and an experimental one. Honestly, the overhead of simply having another package is probably going to be at least as great as the overhead of installing scripts for all init systems, and will be paid in part by everyone: * the repository index gets larger - more disk space and bandwidth from the mirrors - more disk space and bandwidth required for the systems * the dpkg/apt package database gets larger * it gets harder to manually upgrade/downgrade packages * it gets harder to switch inits, due to the maze of initscripts that will need to be installed for each new package I see some comments that seem to assume that every init script should imply a dependency on the corresponding init system. A dependency is for a package without which the package would be unusable for its normal use (IIRC). If you use runit with a daemon that supports upstart, runit, and sysvinit, running /etc/init.d/
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 17:06:17 +0200 Laurent Bercot wrote: > On 18/06/2015 16:15, Steve Litt wrote: > > I was envisioning Devuan people making the defs and runscripts, not > > the authors of the init systems. It would be crazy for us to think > > you, or someone in your position, would write AND MAINTAIN between > > 30 and 200 run scripts. That's crazy. What wouldn't be crazy would > > be for two or three Devuan people to write and maintain a fleet of > > s6 run scripts. > > But my point is that it's crazy no matter who does it! Devuan people > aren't superhuman. How do you expect to give every script the > attention it requires and deserves if you're maintaining 200 of them? > If I, an upstreamer, make a small change to a daemon's interface, > the change has to be reflected in the service scripts; if I make one > such change a month, it's definitely manageable for you, packager, as > long as I'm the only one doing it - but if every upstreamer you have > is doing the same thing, you'll go bonkers in no time. You could make a million changes a day, but unless the changes were to the program's interface as seen from the command prompt, no init action is needed. If I were the run script maintainer and a project started making *interface* changes once a month or even twice a year, I'd code my run script to throw up a screen saying "sorry, project x changes too much, get the run script from the upstream." With the possible exception of dbus, I don't see many interface changes over the years. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 17:37, Hendrik Boom wrote: On Thu, Jun 18, 2015 at 05:26:28PM +0200, Anto wrote: Hello Steve, I don't think we can leave sysvinit as it is now if we want to treat it the same as other inits. I think we need to remove sysvinit specific files from all daemon packages, otherwise they will pull sysvinit specific files as well when we install them under other inits. But that's wxactly what we would want if, as proposed in this discussion somewhere, we are to automate creation of init scripts for another init script by reading the sysv-init scripts. It has even been proposed using systemd init scripts for this purpose! -- hendrik Yes. Perhaps that is what you and some people want. But that is not what I want from the beginning as I want to have a distro that supports some init systems but they should be independent to each other. I think that is only achievable if sysvinit is being treated the same as other inits, not that other inits depend on sysvinit. In the case of epoch, *I think* it can not even use init script provided by daemons package for sysvinit as epoch needs to have direct control over the daemons. I could not get confirmation from epoch maintainer about this though. But who am I to demand that to be implemented in Devuan? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 05:26:28PM +0200, Anto wrote: > > > Hello Steve, > > I don't think we can leave sysvinit as it is now if we want to treat > it the same as other inits. I think we need to remove sysvinit > specific files from all daemon packages, otherwise they will pull > sysvinit specific files as well when we install them under other > inits. But that's wxactly what we would want if, as proposed in this discussion somewhere, we are to automate creation of init scripts for another init script by reading the sysv-init scripts. It has even been proposed using systemd init scripts for this purpose! -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 05:06:17PM +0200, Laurent Bercot wrote: > On 18/06/2015 16:15, Steve Litt wrote: > >I was envisioning Devuan people making the defs and runscripts, not the > >authors of the init systems. It would be crazy for us to think you, or > >someone in your position, would write AND MAINTAIN between 30 and 200 > >run scripts. That's crazy. What wouldn't be crazy would be for two or > >three Devuan people to write and maintain a fleet of s6 run scripts. > > But my point is that it's crazy no matter who does it! Devuan people > aren't superhuman. How do you expect to give every script the attention > it requires and deserves if you're maintaining 200 of them? > If I, an upstreamer, make a small change to a daemon's interface, the > change has to be reflected in the service scripts; if I make one such > change a month, it's definitely manageable for you, packager, as long as > I'm the only one doing it - but if every upstreamer you have is doing the > same thing, you'll go bonkers in no time. > > You were complaining about the difficulty of managing the VimOutliner > package; well, if the package maintainer was responsible for a hundred > other upstreamers, it's really no wonder. And you're suggesting that > two or three poor Devuan maintainers take up a fleet of s6 - or other - > scripts in one unique package, while making sure things are kept clean > and simple and don't become as overloaded as Debian init scripts did? > In one year they'll flip tables and go raise goats in Africa in order to > never have to touch a computer again. > +1 I agree that maintaining all the init scripts in a single package is not just crazy but practically impossible. A quick: enzo@kaa:~$ apt-file -x search /etc/init.d/ | wc -l 1201 enzo@kaa:~$ should clarify any remaining doubt HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 04:22:15PM +0100, KatolaZ wrote: > > I agree that maintaining all the init scripts in a single package is > not just crazy but practically impossible. A quick: Just like maintaining all the printer drivers in one cups. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 15:47, Steve Litt wrote: On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich wrote: On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that "just works". I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key [snip] Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the "upstream" has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no "help" from the "upstreams". We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. Why not leave sysvinit just how it is? It works. It's been working for 20 years. My suggestion was a big box of Epoch defs, and a big box of Daemontools[-encore] runscripts, and a big box of s6 runscripts, and a big box of runit runscripts. apt-get install epoch-scripts The preceding just lays down the Epoch defs somewhere from which you can copy and paste them. Or, if somebody is cool enough to write a program, the program can copy and paste them. The same would be true, respective of init system, for s6-scripts, daemontools-scripts, and runit-scripts. Amount of work: Minimal Amount of rework: Zero Toes stepped on: None Extra work for "upstreams": Zero This might start out as a 100% user driven thing, with the user copying and pasting according to a README file. Later, as we have success with it and understand the nature of automation needed by the user, we can provide programs to automate it, right alongside the big box of scripts. By slowly progressing from user-driven to automated, we can get *something* out there quickly. Think of it as agile packaging :-) Hello Steve, I don't think we can leave sysvinit as it is now if we want to treat it the same as other inits. I think we need to remove sysvinit specific files from all daemon packages, otherwise they will pull sysvinit specific files as well when we install them under other inits. I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init Who, too much for me! Too much for most people. Entangled. Leave OpenRC, Upstart, systemd and sysvinit alone: They already work (well, except for systemd). If the user wants Epoch, just give him the tools for Epoch, and leave the rest where it sits. Same with daemontools-encore, s6 or runit. What Daniel explains is actually I think the same as what I had in mind. I would imagine by doing that, only files specific to the init that is currently running will be pulled when we install the daemon package. And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virtual package "init" (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing that because sysvinit-core is the package providing init that it must also install -sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/2015 16:57, Hendrik Boom wrote: I assume that aptitude has enough algorithmic capacity to do this, but when things get complicated there may not be enough computational power to carry out this analysis in available time and space. My experience is that we have way more computational power than we think, and most inefficiencies come from the implementation, not the amount of work there is to perform. I'm working on a dependency manager. At some point, I have to do some operation in O(n^2), n being the number of services; there's no other choice. But it's still blazingly fast, and you can have up to thousands of services with sub-second execution times. Modern computers are powerful, and data size is nothing to be afraid of - as opposed to program size, which must be handled by humans. So, yeah, if aptitude can handle package dependencies, just feed it, make it work. Even if you have disjunctions - and disjunctions are algorithmically expensive - it's not what will take the most time. Unless, of course, the engine is written in Python or something equally unsuited. Bow, since its possible to have seeral init systems installedd, and even to have different subsytems started by different init systems (not all running as PID 1, of course), perhaps the mutual exclusion among the init systems is a bad idea. Absolutely. Why enforce exclusion when you can have a choice ? Make a "currently active" vs. "inactive" switch, I don't know the Debian/Devuan terminology, and allow users to install both. But I can't recommend this be done for davuan jessie. Too soon, and it would make jessie too late. I think we're all planning for the future, here - get Jessie out first, and then small steps, one at a time. :) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/2015 16:15, Steve Litt wrote: I was envisioning Devuan people making the defs and runscripts, not the authors of the init systems. It would be crazy for us to think you, or someone in your position, would write AND MAINTAIN between 30 and 200 run scripts. That's crazy. What wouldn't be crazy would be for two or three Devuan people to write and maintain a fleet of s6 run scripts. But my point is that it's crazy no matter who does it! Devuan people aren't superhuman. How do you expect to give every script the attention it requires and deserves if you're maintaining 200 of them? If I, an upstreamer, make a small change to a daemon's interface, the change has to be reflected in the service scripts; if I make one such change a month, it's definitely manageable for you, packager, as long as I'm the only one doing it - but if every upstreamer you have is doing the same thing, you'll go bonkers in no time. You were complaining about the difficulty of managing the VimOutliner package; well, if the package maintainer was responsible for a hundred other upstreamers, it's really no wonder. And you're suggesting that two or three poor Devuan maintainers take up a fleet of s6 - or other - scripts in one unique package, while making sure things are kept clean and simple and don't become as overloaded as Debian init scripts did? In one year they'll flip tables and go raise goats in Africa in order to never have to touch a computer again. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 04:06:00PM +0200, Laurent Bercot wrote: > On 18/06/2015 15:47, Steve Litt wrote: > >>I expect the dependency chain should be something like: > >> depends on: init, -sysv-init | -epoch-init | > >>-systemd-init | -openrc-init | -upstart-init > > > >Who, too much for me! Too much for most people. Entangled. > > Still, it is an accurate representation of the dependencies. Now I presume the various init-script packages depend on the init systems. And if the various init systems mutually exclude each other, then presumably aptitude has to thread its way through a maze to find the particular that's already installed and hence - package that's needed. Don't want another init system installed just because aptitude picked the wrong choice in the "-sysv-init | -epoch-init | ..." list. I assume that aptitude has enough algorithmic capacity to do this, but when things get complicated there may not be enough computational power to carry out this analysis in available time and space. Bow, since its possible to have seeral init systems installedd, and even to have different subsytems started by different init systems (not all running as PID 1, of course), perhaps the mutual exclusion among the init systems is a bad idea. What is perhaps needed for the - packages is for the package manager do recognise a request that the - package be installed if and only if the package has been installed and the package has also been installed. This would require changes in the package manager and would likely delay the devuan jessie release. Such cojunctive reverse dependencies would bw useful in a lot of other cases, such as bindings between programming languages and libraries. But I can't recommend this be done for davuan jessie. Too soon, and it would make jessie too late. -- hendrik > If it > is too complex, then we need to figure out a way to make it look > simpler. The average user doesn't need to know what the whole graph > is, and the packager is supposed to be able to understand something > as simple as the separation between the mechanism (daemon) and the > policy (how to start the daemon). > > -- > Laurent > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 16:06:00 +0200 Laurent Bercot wrote: > I think the original point was to spread the maintenance burden. If > you gather all the service definitions for one service manager in one > package, then you centralize the maintenance burden - who will want > to be responsible for that package ? Even as the author of s6, with a > strong desire to have s6 be widely used in a mainstream distribution, > I am *not* going to write and maintain s6-compatible service > definitions for every daemon under the sun - this is crazy work. On > the other hand, if every daemon has its service definition for > whatever service manager in a separate package, it all becomes much > more manageable. I was envisioning Devuan people making the defs and runscripts, not the authors of the init systems. It would be crazy for us to think you, or someone in your position, would write AND MAINTAIN between 30 and 200 run scripts. That's crazy. What wouldn't be crazy would be for two or three Devuan people to write and maintain a fleet of s6 run scripts. Truth be told, I was envisioning *myself* as one of those people. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/2015 15:47, Steve Litt wrote: I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init Who, too much for me! Too much for most people. Entangled. Still, it is an accurate representation of the dependencies. If it is too complex, then we need to figure out a way to make it look simpler. The average user doesn't need to know what the whole graph is, and the packager is supposed to be able to understand something as simple as the separation between the mechanism (daemon) and the policy (how to start the daemon). My thought is there are some packaging tasks better done by a five step README doc. All this package dependency described in this email is an example. Instead, just have one package that installs Epoch, with the epoch program in /sbin. Have another package that puts common Epoch daemon defs in a directory, ready for copying and pasting. Just because one installs Epoch doesn't mean he wants to blow off sysvinit. One more thing: There are *huge* benefits of being able to choose your init, at runtime, just by changing your Grub or LILO init= value. I think the original point was to spread the maintenance burden. If you gather all the service definitions for one service manager in one package, then you centralize the maintenance burden - who will want to be responsible for that package ? Even as the author of s6, with a strong desire to have s6 be widely used in a mainstream distribution, I am *not* going to write and maintain s6-compatible service definitions for every daemon under the sun - this is crazy work. On the other hand, if every daemon has its service definition for whatever service manager in a separate package, it all becomes much more manageable. You know, I used to be an "upstream" (VimOutliner). My co developers and I used to joke about how Debian's package invariably turned a simple concept of a few copy commands into something that often failed and left us no clues with which to troubleshoot. And of course there was Debian's steadfastly changing the very essential Vimoutliner command keystroke to something MUCH more time consuming. As a first troubleshooting measure, we started recommending to Debianists that they install direct from our tarball, following the instructions in that tarball. 80% of the time that fixed the problem, and the other 20% it made it trivial for us to go in and troubleshoot. As an upstreamer, it's natural that you support the tarball over distribution packages: you are responsible for the tarball and can act on bug-reports for the tarball, you have no such power over a package that you do not maintain yourself. However, I think your anecdote supports package explosion: it is easier to find a good, willing, active maintainer for a small, specialized package than for an all-encompassing one. I think we should always make sure packaging makes things easier, not harder. Definitely, but I don't think separating daemon from daemon-init-$servicemanager would make things harder than they already are, on the contrary. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich wrote: > On 18/06/15 10:43, Steve Litt wrote: > > On Wed, 17 Jun 2015 21:27:21 +0200 > > Anto wrote: > > > >> > >> > >> On 17/06/15 17:37, Steve Litt wrote: > >>> Hi all, > >>> > >>> After the recent discussions, I'd like to point out that packages > >>> aren't the ONLY path to alternate inits. I've personally > >>> demonstrated that with SucklessInit+daemontoolsEncore, > >>> SucklessInit+s6, runit, and Epoch, it's quite doable to download, > >>> build, and install these things in parallel to each other. > >>> > >>> I fully endorse the effort to put alternative inits in packages. > >>> It would be wonderful to have, for instance, an Epoch package that > >>> "just works". I also endorse those individuals who go the > >>> out-of-package route. > >>> > >>> Thanks, > >>> > >>> SteveT > >>> > >>> Steve Litt > >>> June 2015 featured book: The Key to Everyday Excellence > >>> http://www.troubleshooters.com/key > >>> [snip] > > > > > > Yes. I have a suggestion. I suggest we just start assembling a > > group of Epoch object descriptions for the top 30 most used > > daemons. Then, as people request them of other daemons, we add > > those. I suggest we keep these as a group of scripts, *not* as > > anything the "upstream" has to worry about. > > > > Look how this works: In 3 weeks we can have 30 Epoch daemon object > > recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 > > weeks we've satisfied 80% of the people, with no "help" from the > > "upstreams". We let people know that if they need an Epoch object > > description for a given daemon we don't yet support, we'll treat > > that like a bug report and make such a Epoch object description. As > > time goes on we'll have a big library of these things, and people > > will notice that Epoch object descriptions are an order of > > magnitude easier to understand, and therefore to DIY, as sysvinit > > scripts. Probably easier than systemd unit files too, given that > > I've never heard any person describe how systemd actually works. > > > > You can have most of your easy Epoch installation, on Devuan, in 3 > > weeks. I have virtual machines, so I can help. It will be fun. And > > you know what? I might just take each of those Epoch object > > descriptions, and make a daemontools/daemontools-encore/runit/s6 > > run file based on it. > > > > I wonder if now is the time to start separating out the init specific > configuration files, initscripts or service files, libraries and > binaries out into separate packages so that any particular init can > be supported without treading on the toes of others. The only issue > I can see with this is the dependency chain can get a bit hairy. Why not leave sysvinit just how it is? It works. It's been working for 20 years. My suggestion was a big box of Epoch defs, and a big box of Daemontools[-encore] runscripts, and a big box of s6 runscripts, and a big box of runit runscripts. apt-get install epoch-scripts The preceding just lays down the Epoch defs somewhere from which you can copy and paste them. Or, if somebody is cool enough to write a program, the program can copy and paste them. The same would be true, respective of init system, for s6-scripts, daemontools-scripts, and runit-scripts. Amount of work: Minimal Amount of rework: Zero Toes stepped on: None Extra work for "upstreams": Zero This might start out as a 100% user driven thing, with the user copying and pasting according to a README file. Later, as we have success with it and understand the nature of automation needed by the user, we can provide programs to automate it, right alongside the big box of scripts. By slowly progressing from user-driven to automated, we can get *something* out there quickly. Think of it as agile packaging :-) > > I expect the dependency chain should be something like: > depends on: init, -sysv-init | -epoch-init | > -systemd-init | -openrc-init | -upstart-init Who, too much for me! Too much for most people. Entangled. Leave OpenRC, Upstart, systemd and sysvinit alone: They already work (well, except for systemd). If the user wants Epoch, just give him the tools for Epoch, and leave the rest where it sits. Same with daemontools-encore, s6 or runit. > > And if each of those -*-init packages depended on their > respective init system, and each of those init systems provide the > virtual package "init" (as is the case in Debian and Devuan Jessie), > then apt should be able to work out that when installing > that because sysvinit-core is the package providing init that it must > also install -sysv-init in order to satisfy the dependency. > The problem is whether changing init systems would result in pulling > in the new -*-init dependency required for the new init > system. > > Thoughts?? My thought is there are some packaging tasks better done by a five step README doc. All this package dependency described in this email is an example. Instead, just have on
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 12:04:33PM +, Noel Torres wrote: > Maybe a compromise solution is to do this for all init systems but sysvinit, > for Jessie, and work on the fully "hairy" dependency chain for Jessie+1 > a.k.a Ascii. > Devuan jessie will not see anything like that. For jessie we need to focus to release as early as possible and to stay more close to debian as we can, just removing systemd and using sysvinit and few other non critical changes. We can think about change anything we want to do starting from ascii, so, amy proposition is welcome to be experimented and tested following the usual path experimental -> if accepted going to ceres -> after 10 day in ceres with no critical bugs can migrate to ascii. -- Franco (nextime) Lanza Lonate Pozzolo (VA) - Italy SIP://c...@casa.nexlab.it web: http://www.nexlab.net NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 11:29, Daniel Reurich wrote: On 18/06/15 10:43, Steve Litt wrote: Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the "upstream" has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no "help" from the "upstreams". We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virtual package "init" (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing that because sysvinit-core is the package providing init that it must also install -sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new -*-init dependency required for the new init system. Thoughts?? Hello Daniel, That would be really great, especially if the *now is the time* that you mentioned is for Devuan jessie. But I think you and other Devuan developers have already a lot on your plates. And I believe releasing Devuan jessie with sysvinit was the initial plan and it has the highest priority. That is why I always use the subject *I* on my emails here, instead of *we*, because *we* usually implies "we would like to have that and could *you* please implement that for us" :) Perhaps after Devuan jessie gains popularity, *we* could start diverting further from the road that Debian takes. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 19/06/15 00:04, Noel Torres wrote: Didier Kryn escribió: [...] I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virtual package "init" (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing that because sysvinit-core is the package providing init that it must also install -sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new -*-init dependency required for the new init system. Thoughts?? This is the normal way of implementing this kind of multiple alternative dependencies in Debian, AFAIU. The only reason I did not advocate this before is that it would bring in a bunch of new packages each containing only one small file. But this might not be a big deal after all, considering it solves the problem completely, allows to get rid of the irritating systemd service files, and treats all other init systems equally. I support this idea. Didier I support it as well, but this implies the extra work of putting the sysvinit scripts in separate packages, and that's quite a lot of work, and deepens the Delta with our Upstream (a.k.a. Debian), so when they fix something (e.g. a bug in Apache) we will need to port that to our package, instead of just copying their package. It's just a change in the control file and install files in debian/ for the package. No big deal really. Maybe a compromise solution is to do this for all init systems but sysvinit, for Jessie, and work on the fully "hairy" dependency chain for Jessie+1 a.k.a Ascii. That could work, but there is nothing stop starting that work in ascii now (except all the work needed to get Jessie out the door). -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Didier Kryn escribió: [...] I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virtual package "init" (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing that because sysvinit-core is the package providing init that it must also install -sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new -*-init dependency required for the new init system. Thoughts?? This is the normal way of implementing this kind of multiple alternative dependencies in Debian, AFAIU. The only reason I did not advocate this before is that it would bring in a bunch of new packages each containing only one small file. But this might not be a big deal after all, considering it solves the problem completely, allows to get rid of the irritating systemd service files, and treats all other init systems equally. I support this idea. Didier I support it as well, but this implies the extra work of putting the sysvinit scripts in separate packages, and that's quite a lot of work, and deepens the Delta with our Upstream (a.k.a. Debian), so when they fix something (e.g. a bug in Apache) we will need to port that to our package, instead of just copying their package. Maybe a compromise solution is to do this for all init systems but sysvinit, for Jessie, and work on the fully "hairy" dependency chain for Jessie+1 a.k.a Ascii. Just my one-and-a-half cents Envite from beneath the forgotten binJ1xeSuyOGL.bin Description: Clave PGP pública pgpnnt8z9CK3V.pgp Description: Firma digital PGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Le 18/06/2015 11:29, Daniel Reurich a écrit : On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that "just works". I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Hello Steve, I agree with you that packaging epoch init system is not the only way to have it as alternate init. However, that depends on the type of PC which we would use epoch init system on. What I plan to do is to have epoch init system on a regular PC which I am using everyday. So not on a test PC where I can do a lot of crazy things then just bin the idea if I am not happy and wipe the whole hard disk. On a regular PC, I want to be able to *easily* install and uninstall packages as I normally do, including switch back to sysvinit. And I want epoch init to be able to manage the daemons which might come from those packages, e.g. wicd package to manage my WiFi connection. For this purpose, I think the only way to be able to use epoch init system is to have it as a package, especially on Debian based distros. From what I have gathered and understood so far, I have 4 options to use epoch init system: 1. As I want to use Devuan, I have to patch all packages containing daemons that I want to use with epoch init configuration, build epoch package according to the packaging rules, compile them and install them as standard package. 2. If I still insisted to use Devuan but I don't want to go through all troubles on option 1, I compile epoch using the upstream build script, manually install the compiled bin files, manually add the daemons init configurations into epoch.conf. Along the time, I will have to manually add epoch init configuration into epoch.conf, for every packages with daemons that I install. And I will have to deal with all issues related to those packages due to the incompatibilities between epoch and sysvinit. 3. I don't want to keep following Debian rules, so I develop my own distro with my own rules and my own package manager. The works for that will possibly be more than for both previous options, but I will have control over everything. 4. Or I just use LFS with epoch init system. Seriously, with my current knowledge and experience, you can be sure that I will fail if I would do any of the first 3 options. So the only feasible option is the last one. But why am I here making noise if I didn't want to use Devuan? So what am I going to do about this now a part from to forget about this and move on? Do you or anyone else have suggestions? Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the "upstream" has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no "help" from the "upstreams". We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, a
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that "just works". I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Hello Steve, I agree with you that packaging epoch init system is not the only way to have it as alternate init. However, that depends on the type of PC which we would use epoch init system on. What I plan to do is to have epoch init system on a regular PC which I am using everyday. So not on a test PC where I can do a lot of crazy things then just bin the idea if I am not happy and wipe the whole hard disk. On a regular PC, I want to be able to *easily* install and uninstall packages as I normally do, including switch back to sysvinit. And I want epoch init to be able to manage the daemons which might come from those packages, e.g. wicd package to manage my WiFi connection. For this purpose, I think the only way to be able to use epoch init system is to have it as a package, especially on Debian based distros. From what I have gathered and understood so far, I have 4 options to use epoch init system: 1. As I want to use Devuan, I have to patch all packages containing daemons that I want to use with epoch init configuration, build epoch package according to the packaging rules, compile them and install them as standard package. 2. If I still insisted to use Devuan but I don't want to go through all troubles on option 1, I compile epoch using the upstream build script, manually install the compiled bin files, manually add the daemons init configurations into epoch.conf. Along the time, I will have to manually add epoch init configuration into epoch.conf, for every packages with daemons that I install. And I will have to deal with all issues related to those packages due to the incompatibilities between epoch and sysvinit. 3. I don't want to keep following Debian rules, so I develop my own distro with my own rules and my own package manager. The works for that will possibly be more than for both previous options, but I will have control over everything. 4. Or I just use LFS with epoch init system. Seriously, with my current knowledge and experience, you can be sure that I will fail if I would do any of the first 3 options. So the only feasible option is the last one. But why am I here making noise if I didn't want to use Devuan? So what am I going to do about this now a part from to forget about this and move on? Do you or anyone else have suggestions? Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the "upstream" has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no "help" from the "upstreams". We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems provide the virt
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 00:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that "just works". I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Hello Steve, I agree with you that packaging epoch init system is not the only way to have it as alternate init. However, that depends on the type of PC which we would use epoch init system on. What I plan to do is to have epoch init system on a regular PC which I am using everyday. So not on a test PC where I can do a lot of crazy things then just bin the idea if I am not happy and wipe the whole hard disk. On a regular PC, I want to be able to *easily* install and uninstall packages as I normally do, including switch back to sysvinit. And I want epoch init to be able to manage the daemons which might come from those packages, e.g. wicd package to manage my WiFi connection. For this purpose, I think the only way to be able to use epoch init system is to have it as a package, especially on Debian based distros. From what I have gathered and understood so far, I have 4 options to use epoch init system: 1. As I want to use Devuan, I have to patch all packages containing daemons that I want to use with epoch init configuration, build epoch package according to the packaging rules, compile them and install them as standard package. 2. If I still insisted to use Devuan but I don't want to go through all troubles on option 1, I compile epoch using the upstream build script, manually install the compiled bin files, manually add the daemons init configurations into epoch.conf. Along the time, I will have to manually add epoch init configuration into epoch.conf, for every packages with daemons that I install. And I will have to deal with all issues related to those packages due to the incompatibilities between epoch and sysvinit. 3. I don't want to keep following Debian rules, so I develop my own distro with my own rules and my own package manager. The works for that will possibly be more than for both previous options, but I will have control over everything. 4. Or I just use LFS with epoch init system. Seriously, with my current knowledge and experience, you can be sure that I will fail if I would do any of the first 3 options. So the only feasible option is the last one. But why am I here making noise if I didn't want to use Devuan? So what am I going to do about this now a part from to forget about this and move on? Do you or anyone else have suggestions? Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the "upstream" has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no "help" from the "upstreams". We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Thanks Steve, It looks like that you suggested to go for option 2. I actually tend to go for option 3 especially that I have already cleaned up more than what Devuan does and recompiled all packages on my PC that I am using now to write this email. But I have to be realistic as I need a lot more than that to build a new distro. My knowledge and experience on this is also still quite thin so I have very high chance to fail. I must do this slowly step by step if I want to succeed, starting by learnin
Re: [DNG] Packages aren't the only path to alternate inits
On Wed, 17 Jun 2015 21:27:21 +0200 Anto wrote: > > > On 17/06/15 17:37, Steve Litt wrote: > > Hi all, > > > > After the recent discussions, I'd like to point out that packages > > aren't the ONLY path to alternate inits. I've personally > > demonstrated that with SucklessInit+daemontoolsEncore, > > SucklessInit+s6, runit, and Epoch, it's quite doable to download, > > build, and install these things in parallel to each other. > > > > I fully endorse the effort to put alternative inits in packages. It > > would be wonderful to have, for instance, an Epoch package that > > "just works". I also endorse those individuals who go the > > out-of-package route. > > > > Thanks, > > > > SteveT > > > > Steve Litt > > June 2015 featured book: The Key to Everyday Excellence > > http://www.troubleshooters.com/key > > > > Hello Steve, > > I agree with you that packaging epoch init system is not the only way > to have it as alternate init. However, that depends on the type of PC > which we would use epoch init system on. > > What I plan to do is to have epoch init system on a regular PC which > I am using everyday. So not on a test PC where I can do a lot of > crazy things then just bin the idea if I am not happy and wipe the > whole hard disk. On a regular PC, I want to be able to *easily* > install and uninstall packages as I normally do, including switch > back to sysvinit. And I want epoch init to be able to manage the > daemons which might come from those packages, e.g. wicd package to > manage my WiFi connection. For this purpose, I think the only way to > be able to use epoch init system is to have it as a package, > especially on Debian based distros. > > From what I have gathered and understood so far, I have 4 options to > use epoch init system: > > 1. As I want to use Devuan, I have to patch all packages containing > daemons that I want to use with epoch init configuration, build epoch > package according to the packaging rules, compile them and install > them as standard package. > > 2. If I still insisted to use Devuan but I don't want to go through > all troubles on option 1, I compile epoch using the upstream build > script, manually install the compiled bin files, manually add the > daemons init configurations into epoch.conf. Along the time, I will > have to manually add epoch init configuration into epoch.conf, for > every packages with daemons that I install. And I will have to deal > with all issues related to those packages due to the > incompatibilities between epoch and sysvinit. > > 3. I don't want to keep following Debian rules, so I develop my own > distro with my own rules and my own package manager. The works for > that will possibly be more than for both previous options, but I will > have control over everything. > > 4. Or I just use LFS with epoch init system. > > Seriously, with my current knowledge and experience, you can be sure > that I will fail if I would do any of the first 3 options. So the > only feasible option is the last one. But why am I here making noise > if I didn't want to use Devuan? > > So what am I going to do about this now a part from to forget about > this and move on? Do you or anyone else have suggestions? Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the "upstream" has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no "help" from the "upstreams". We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that "just works". I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Hello Steve, I agree with you that packaging epoch init system is not the only way to have it as alternate init. However, that depends on the type of PC which we would use epoch init system on. What I plan to do is to have epoch init system on a regular PC which I am using everyday. So not on a test PC where I can do a lot of crazy things then just bin the idea if I am not happy and wipe the whole hard disk. On a regular PC, I want to be able to *easily* install and uninstall packages as I normally do, including switch back to sysvinit. And I want epoch init to be able to manage the daemons which might come from those packages, e.g. wicd package to manage my WiFi connection. For this purpose, I think the only way to be able to use epoch init system is to have it as a package, especially on Debian based distros. From what I have gathered and understood so far, I have 4 options to use epoch init system: 1. As I want to use Devuan, I have to patch all packages containing daemons that I want to use with epoch init configuration, build epoch package according to the packaging rules, compile them and install them as standard package. 2. If I still insisted to use Devuan but I don't want to go through all troubles on option 1, I compile epoch using the upstream build script, manually install the compiled bin files, manually add the daemons init configurations into epoch.conf. Along the time, I will have to manually add epoch init configuration into epoch.conf, for every packages with daemons that I install. And I will have to deal with all issues related to those packages due to the incompatibilities between epoch and sysvinit. 3. I don't want to keep following Debian rules, so I develop my own distro with my own rules and my own package manager. The works for that will possibly be more than for both previous options, but I will have control over everything. 4. Or I just use LFS with epoch init system. Seriously, with my current knowledge and experience, you can be sure that I will fail if I would do any of the first 3 options. So the only feasible option is the last one. But why am I here making noise if I didn't want to use Devuan? So what am I going to do about this now a part from to forget about this and move on? Do you or anyone else have suggestions? Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
