On 18/06/15 15:47, Steve Litt wrote:
> On Thu, 18 Jun 2015 21:29:36 +1200
> Daniel Reurich <daniel@???> wrote:
>
>> On 18/06/15 10:43, Steve Litt wrote:
>>> On Wed, 17 Jun 2015 21:27:21 +0200
>>> Anto <aryanto@???> 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