Hello, On Sun, Dec 28, 2014 at 3:47 AM, Laurent Bercot <ska-supervis...@skarnet.org> wrote: > > 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. > 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.
Feature-Request: Why not have a non-fs-root install configuration option that takes care of what the OP wanted to get done ? then you a configure script that is more sane and more adaptable to anyone's needs. Just my not so thorough two cents to the discussion. Warm regards, Harish On Sun, Dec 28, 2014 at 3:47 AM, Laurent Bercot <ska-supervis...@skarnet.org> wrote: > > 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 skaw...@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 >
