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 flor...@zwischenspeicher.info wrote: On Thu, 18 Jun 2015 16:58:59 +0200 Mat m...@parad0x.org 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 sl...@troubleshooters.com 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 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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 m...@parad0x.org -- Mat m...@parad0x.org 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 Thu, 18 Jun 2015 16:58:59 +0200 Mat m...@parad0x.org 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 sl...@troubleshooters.com 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 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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-init system name which should declare a Breaks with all the other init-default-init system name 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-init-system name 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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-init system name which should declare a Breaks with all the other init-default-init system name 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
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 Fri, Jun 19, 2015 at 11:33 PM, Didier Kryn k...@in2p3.fr 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
Riccardo Boninsegna: On Fri, Jun 19, 2015 at 11:33 PM, Didier Kryn k...@in2p3.fr 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
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 19/06/15 00:04, Noel Torres wrote: Didier Kryn k...@in2p3.fr escribió: [...] I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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
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 arya...@chello.at 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-init
Re: [DNG] Packages aren't the only path to alternate inits
Didier Kryn k...@in2p3.fr escribió: [...] I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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
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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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 Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich dan...@centurion.net.nz wrote: On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-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 daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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
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 15:47, Steve Litt wrote: On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich dan...@centurion.net.nz wrote: On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-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 daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 16:06:00 +0200 Laurent Bercot ska-de...@skarnet.org 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 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: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-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 initsystem that's already installed and hence daemon-initsystem package that's needed. Don't want another init system installed just because aptitude picked the wrong choice in the daemon-sysv-init | daemon-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 daemon-initsystem packages is for the package manager do recognise a request that the daemon-initsystem package be installed if and only if the daemon package has been installed and the initsystem 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). snip -- 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 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 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 09:47:21AM -0400, Steve Litt wrote: On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich dan...@centurion.net.nz wrote: [snip] And if each of those daemon-*-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 daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-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/script is not part of your normal use; there is no reason to depend on sysvinit except perhaps this way: Recommends: sysv-rc | upstart | runit As far as quantity of work goes, you may need to do more than just 30 daemons to get a moderately featureful desktop going. But maintaining the scripts separately is probably going to be easier than adopting each of the packages. You won't be maintaining scripts for all 1000+ packages: epoch users probaly won't want heartbeat, or the three UPS packages. If you do maintain scripts for separately maintained daemons, mark your packages as enhancing them. HTH, Isaac Dunham ___ 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 17:06:17 +0200 Laurent Bercot ska-de...@skarnet.org 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 00:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at 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
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
Re: [DNG] Packages aren't the only path to alternate inits
On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at 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
[DNG] Packages aren't the only path to alternate inits
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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
