1:49 p.m.
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.
I'd like to ask: what does this mean for developers or users like 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)
Thanks for your time and consideration.
~zlg
--
https://zlg.space/ | gopher://zlg.space/1/
OpenPGP fpr: 8C5B 31C2 A9B0 B97C 22C7 96ED 593C 6C93 2F3F ABB7
3:59 p.m.
Hi,
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.
Note that there has never been the suggestion to _remove_ OpenRC. s6-linux-init
is not a replacement for OpenRC; they serve entirely different functions. If s6
replaces anything, it would be sysvinit; and even then the user interface to
"init" stays mostly the same. The only difference would be that /etc/inittab is
replaced by the pair of scripts /etc/rc.init and /etc/rc.shutdown (gettys are
already removed from /etc/inittab).
None of that affects OpenRC's interface. In fact, OpenRC already has official s6
integration upstream (from Gentoo). This integration means that, instead of
starting daemons directly (or using a helper such as start-stop-daemon), OpenRC
delegates supervision to s6. This provides the benefits of more reliable
logging, more reliable service shutdown, and automatic restarting of services
that crash (all nice features!), while not affecting the service/rc/rc-update
user interface at all.
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.
I'd like to ask: what does this mean for developers or users like
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".
Thanks for your time and consideration.
~zlg
That's my understanding; hopefully it's accurate,
Samuel
8:13 p.m.
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
like
> 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
anything done.
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,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
799
days inactive
800
days old
adelie-devel@lists.adelielinux.org
2 comments
3 participants
participants (3)
-
A. Wilcox -
Samuel Holland -
zlg