supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)
Date: Tue, 16 Jan 2018 15:44:03 +0000	[thread overview]
Message-ID: <em0a1cece3-1e3a-40b3-9550-4d0e1e29f92b@elzian> (raw)
In-Reply-To: <89cffa18-a72a-ed98-031c-c72fc00ad5aa@ntlworld.com>

>You have prompted me to fill in a long-standing dangling hyperlink.
>
>* http://jdebp.eu./FGA/slashpackage.html

  If I may add my two cents: I think you're mixing two very different
things in this page.

  There is the slashpackage convention for installed packages, i.e.
visibility of executables in /package/category/name/command/name
and the like. I find it useful; and my software *still follows* that
convention, if compiled with --enable-slashpackage.

  And there is the internal structure for building packages, which is
package/compile, package/run, etc. I liked its simplicity at first,
but with experience, I found that it wasn't ideal.

  The primary issue is that it's inherently not cross-compile-friendly.
Having a pre-written compilation script makes it difficult to separate
gathering information about the target and actually building for the
target; whereas a configure/make system can frontload the data
gathering operation. (And in my case I frontload it all in the
skalibs package, so when the annoying part of finding correct sysdeps
for the target has been done once, all the rest of the software
cross-compiles effortlessly.)

  A secondary issue is that system administrators and distribution
packagers, i.e. the intended users of the build system, just could
not stop complaining about it, to the point that complaints about the
build system were for some time the majority of the mailing-list's
traffic. No matter whether their reasons were good or bad, if the
intended users of an interface don't like the interface, then it's
probably a good idea to change the interface. Since switching to
configure/make, the popularity of s6 has skyrocketed; I don't think
it's entirely accidental.

  So yes, the internal package/compile build system is something I
stepped away from. But IMO that's not at all the important part of
the "slashpackage convention", one does not imply the other; and
I wish you would emphasize that.

--
  Laurent



      parent reply	other threads:[~2018-01-16 15:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 23:23 Incompatibilities between runit and s6? Avery Payne
2018-01-11 14:14 ` Charlie Brady
2018-01-13 18:03   ` Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?) Charlie Brady
2018-01-13 18:55     ` Laurent Bercot
2018-01-14 11:36     ` Jonathan de Boyne Pollard
2018-01-14 21:08       ` Charlie Brady
2018-01-14 21:54         ` Jonathan de Boyne Pollard
2018-01-15 12:53           ` Thomas Caravia
2018-01-15 13:33             ` Laurent Bercot
2018-01-16  0:33             ` Charlie Brady
2018-01-16  0:44               ` nosh build problems (Re: Compatibilities between runit and s6 (re: ) Charlie Brady
2018-01-16 16:09                 ` Charlie Brady
2018-01-16 20:51                   ` Jonathan de Boyne Pollard
2018-01-17  1:26                     ` Guillermo
2018-01-17  7:35                       ` Jonathan de Boyne Pollard
2018-01-17 15:25                     ` Charlie Brady
2018-01-18 11:58                       ` Guillermo
2018-01-18 14:25                         ` nosh build problems (Re: Compatibilities between runit and s6 Charlie Brady
2018-02-18 21:16                   ` nosh build problems (Re: Compatibilities between runit and s6 (re: ) Guillermo
2018-01-16  8:10               ` Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?) Jonathan de Boyne Pollard
2018-01-16 15:59                 ` Charlie Brady
2018-01-16 21:51                   ` Jonathan de Boyne Pollard
2018-01-16  8:06             ` Jonathan de Boyne Pollard
2018-01-16 14:52               ` multiplexd
     [not found]             ` <89cffa18-a72a-ed98-031c-c72fc00ad5aa@ntlworld.com>
2018-01-16 15:44               ` Laurent Bercot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=em0a1cece3-1e3a-40b3-9550-4d0e1e29f92b@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).