Re: s6 and friends 2.0

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Sat, 27 Dec 2014 23:17:03 +0100

  Hi Toki,
  Grats on trying out s6.
  Since most of your troubles have to do with skalibs and not with s6 itself,
please use the skaware_at_list.skarnet.org list. (Reply-To: set. I'd set
Mail-Followup-To: if I knew how to tell Thunderbird to do so. >.>)

  My answers below.


> First, a minor note: Why do you keep those two extra digits in the release
> version? I guess MAJOR.MINOR.PATCH are enough most of the times and
> then sometimes a tiny fix would require a SUB-PATCH digit, honestly, one
> can just delay a release a few days, to make sure everything is alright, and
> increment the patch digit.

  That was my opinion as well, until I found that it didn't work in practice.
  The major number hardly ever changes - it basically takes a whole rewrite or
redesign of the project to warrant a major number change. So this one is out
of the picture for day-to-day versioning.
  The minor number, then, should be used for ABI versions. When the minor
number changes, the ABI may change.
  The third number should then be used for API augmentations, minor releases.
  And so a fourth number is needed for bugfixes.
  Basically, since the major number - which I really want to call an
'incarnation number' - is so static, it pushes everything to the right. If I
had my way, I'd use the "incarnation.major.minor.patch" terminology, but I'm
afraid it would be confusing - people are too used to calling the first number
"major".


> Second, why is there this long list of configure directory:

  Because some of them are needed by the functionality, and some of
them are FHS legacy. What part do you think is superfluous ?


> which doe not even respect ABI string when I end up with this:

  ABI string ? What do you mean ?


> * Contents of dev-libs/skalibs-2.0.0.0:

  I'm sorry, but if you're using a packaged version of skalibs,
I can't be held responsible for the way it is packaged. Figuring
out the way the configuration system works and using it to put
the files where they want them is the packager's job.


> Even with configure command line, I still got the double usr mess because
> of the way the configure script hardcode a few paths.
> --
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu

  This configure is not autotools-generated. Those --build and --host
options will not do anything, and it does not necessarily interpret
every option exactly as an autotools-generated configure does. Please
read the output of ./configure --help carefully.

  Also, skalibs is meant to be used by low-level software, which might
even run as process 1. You should not use --prefix=/usr for it: the
dynamic libraries, if you build them, should go into /lib, not /usr/lib.
The static libraries still go by default into /usr/lib/skalibs, because
there's no reason for them to go into /lib - nobody does development
before mounting /usr.
  This is also true, at least, for execline and s6, whose binaries should
go into /bin and not /usr/bin.

  I know there are some distributions out there that use /bin and /usr/bin,
/lib and /usr/lib indiscriminately. This is a mistake. The assumption that
/usr will be on the root filesystem, as well as the assumption that it is
on the local machine at all, is youthist and flippant; skalibs aims to be
portable to platforms where those assumptions may not be true.

  Do not use --prefix for skalibs, execline and s6, and you'll be fine.
The fine-tuning installation directories should allow you to do exactly
what you want. If there is something you cannot do, please post exactly
what you tried, what you expected, and what you got.


> I did not touch s6 main package because I invested too much time in the
> others...

  I commend you for your dedication. However, I daresay it was premature.
I spent a lot - and I mean a lot - of time on the configure script to make
it both sane and adaptable to anyone's needs. (Two conflicting goals.)
No matter what you want to do, if it's not too demented - and that may be
a big if with today's distributions - then there's a way for you to do it,
without having to patch the script. If you can make an autotools-generated
configure script work for you, which is more than I can say for myself,
then there's no way you won't be able to make my configure script work as
well. Please explain what you need as clearly as you can.

-- 
  Laurent
Received on Sat Dec 27 2014 - 22:17:03 UTC

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