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
>
> Whoaaaa, 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