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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
