On 03/03/19 14:59, Samuel Holland wrote:
On 03/03/19 12:49, zlg wrote:
> Over the past few days, conversation in IRC has brought about talk
> of the s6 set of utilities becoming more strongly integrated with
> Adélie, with a hopeful end result of s6 powering init (once
> s6-linux-init is done), services (via s6-rc), and process
> supervision, among other things like tcp wrappers, etc. Talk of
> gutting GNU coreutils was also present.
[ snip ]
s6-rc integration, on the other hand, _would_ be an alternative to
OpenRC, but only as an _additional_ choice. User choice of service
management systems has always been a goal of Adélie -- that's why the
init scripts have been in split packages from the beginning.
That's correct. We want to offer people our users the choice of OpenRC
*or* s6. We do not want to *replace* OpenRC, and we likely wouldn't
look to do that unless OpenRC became unmaintained upstream.
> I'd like to ask: what does this mean for developers or users
> myself who currently use GNU coreutils and OpenRC? What is Adélie's
> official long-term statement on the "main" software stack? (for
> lack of better phrasing)
I don't speak for the project, but my understanding of the coreutils
issue is that, in order to avoid conflict with the FSF, coreutils
should not be in the _base install_. It would _not_ be removed from
the distribution, and you could install it just like any other
package (it would provide cmd:foo for all appropriate binaries, and
apk would take care of handling conflicts), and it would remain
installed on your existing systems. In short, the impact to users
like you should be "none".
That's correct. 'coreutils' would be moved from system/ to user/. We
would likely leave coreutils binaries in /usr/bin and put the new POSIX
conformant binaries in /usr/5bin (which would be the first entry in
$PATH by default, but obviously customisable by users). This would not
only be required to pass VSC, but is also required to not have legal
and/or social issues with FSF. They require all distros that use
coreutils to call themselves "GNU/Linux", instead of "Linux". We are
not GNU-based (we don't ship GNU glibc nor GNU iconv nor GNU gettext etc
etc), and I really do not feel that they deserve top billing.
That is all, however, in the distant future. I doubt it will make 1.0,
unless we have a sudden large influx of resources (developers *and* money).
By "main software stack", I assume you are asking for Adélie's official
statement on the system/ repository. The system/ repository contains
all of the packages needed to (a) build your own base Adélie system from
source, and/or (b) run the base Adélie system. Put another way, system/
is what makes Adélie in to Adélie - user/ is the typical KDE, Mozilla,
etc software that you find on all distributions.
In a major version cycle (for instance 1.X or 2.X), the system/
repository will only ever receive security updates. We haven't
officially decided this, but I'm not sure if I would even accept
non-security bugfixes in to system/. My rationale would be that someone
may be *relying* on a bug or crash in there. At any rate, it would
never see a major version bump or package change. (This is why I was
hesitant to bump GCC 6 to GCC 8. I feel this is a special circumstance
since 1.0 has taken so long, and GCC has moved so far since this began.)
That means that if 1.0 ships with just OpenRC and coreutils, then 1.X
will only ever ship with just OpenRC or coreutils. You would have to
upgrade to 2.x to be able to choose s6-rc, or our POSIX base binaries.
Of course, until 1.0 is actually *shipped*, nothing is finalised. None
of our guarantees hold up during alphas or betas, or we'd never get
Once 1.0 is branched to 1-STABLE, then 'master' will be a pre-alpha of
2.0 and the /current symlink on Adélie mirrors would point to that, so
it isn't like you would have to wait until 2020 if you did want to mess
around with it or test what it felt like.
I hope this explanation is helpful and clarifying. If you would like me
to expand on any of these points, please let me know.
Best to you and yours,
A. Wilcox (awilfox)
Project Lead, Adélie Linux