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 <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
>>>>
>>>
>>> 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 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
::
Re: [DNG] Packages aren't the only …
