Re: Packaging (Re: [announce] s6-

From: Laurent Bercot <>
Date: Tue, 28 Jul 2015 00:12:38 +0200

On 27/07/2015 19:24, Buck Evan wrote:
> Laurent, I assume you have an opinion on Debian packaging. What is it?

  I have lots of opinions, but I tend to avoid giving them when they don't
bring anything to the table, when I don't have anything actionable to
suggest, or when I'm not knowledgeable enough in the field. All three are
true as far as packaging systems are concerned.

  But since you asked, here it is:

  I haven't found a single widespread packaging system that I'm happy with.
Packaging systems are like French ISPs: they all suck, and it's all about
making the best of what you have and working out things yourself, not
about trying to find something better than what you have, because the
grass isn't any greener on the other side.

  The closest thing to something I like as far as packaging is concerned
is slashpackage, minus the global registration (if slashpackage had ever
taken off, without a decent scaling mechanism DJB would have turned insane
in a week) and the split into categories (too arbitrary).

  I usually install foobar manually into /opt/foobar-$version, with
a symlink /opt/foobar -> foobar-$version so /opt/foobar is always the
"current version" and upgrades/rollbacks can be atomic. And more
symlinks like /bin/foobar -> /opt/foobar/bin/foobar .
  This does almost exactly what I want. The main issue I have is global
configuration files: should foobard.conf be /etc/foobard.conf or
/opt/foobar-$version/etc/foobard.conf ? Both have advantages and
drawbacks, and there's no clear-cut answer.

  I'm lucky enough, as a system programmer, to have very few needs in
terms of actual *use* of a Unix system. Give me a terminal and a text
editor and I'm ready to work. I maintain my servers by hand, and my
working environment is a metric ton of terminals with a SSH connection
to the server I'm working on - and I don't care about the client
machine at all. I'll work with the client machine I'm given. My home PC
runs Microsoft Windows - that way, I'm *sure* I'll never be tempted to
go look under the hood to try and improve it, I'll never be tempted to
be a "power user", and it's saving me a lot of time.

  Back when I still believed in GNU/whatever/Linux on the desktop, I
tried a few distros, and looked a bit under the hood of the packaging
systems, but found nothing I was interested in. Debian isn't better than
anything else, and isn't worse either. But I'm really not the guy to
discuss its working details with.

> I've been working for a week on improving a s6-packaging I found on github,
> and I'm still not done.

  Don't hate on the package's authors, because a s6 package is probably
*really* hard to do: you have to make important architectural and political
decisions about how s6-svscan is going to be launched, how it's going to
interact with the rest of the system, where to put compatibility hooks, etc.

  I've found that packaging systems worked reasonably well with application
software, but the closer you got to the system basics, with stuff such as
a shell, /etc/passwd, the rc system or the init system, the more they fell
apart. Because when you're so close to the bare kernel, it becomes more and
more difficult to separate mechanism from policy - you can't package
software (mechanism) without tighly integrating your distro's configuration
choices (policy) into the package. So, for instance, a s6 package will be
vastly different depending on whether you want to run your supervision tree
as a normal service run by your stock rc system (or, in the case of the
newest Debian, by systemd), or you want to make s6-svscan your process 1
with the logging shenanigans and work to ensure compatibility with other
packages assuming a sysvinit interface.

  So, good luck with your work on the s6 package you found. Maybe the original
is good, but simply not compatible with the policy you have in mind, and you
have to do all the work again - which you might accomplish just as well by
starting from scratch. ;)

Received on Mon Jul 27 2015 - 22:12:38 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC