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
Whoaaaa, 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 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.
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.
I think we should always make sure packaging makes things easier, not
harder.
SteveT
Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
One main reason why I use Debian much longer time than other distros is
the dpkg. I can do most things that I want. With yum or yast, I shall
forget about selecting specific version of packages (pinning in dpkg) as
I could not even do simple downgrade of the whole distros. But that was
more than 10 years so I am not sure their status now as I have never
switched to other distros since then. I tried other distros as well but
I could not recall the pain that I had, most probably because I just bin
them. I think dpkg can do that because it can easily solve the
dependencies. But that comes with the price, that a few copy commands
turns into something very complex. On my early days using Debian, I had
indeed a lot of issues with some dependencies which were for me hard to
solve, but those were still solve-able with dpkg without re-installation.
So I don't think installing packages directly from tarball is a good
idea. When asterisk PBX (http://www.asterisk.org/) was not in Debian
repository, I had to compile and install it from source. I had always
issues with its modules on most of every module upgrades, which was
quite hard to solve. My solution was always re-compile everything even
if I just wanted to upgrade. Since it was ported to Debian, I had no
issue any more with upgrading the modules as dpkg smartly manage the
dependencies for me.
Cheers,
Anto
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
