FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 09-27-2012, 01:48 PM
Tom Gundersen
 
Default The future of sysvinit in Arch: Call for Help

Hi guys,

As the move to systemd is under way, and we will soon have packages in
our repos that require your system to be booted with systemd, I
thought this would be a good time to summarize the state of
sysvinit/initscripts in Arch and their future.

Abstract: I think the current state is relatively good (but I'm
clearly very biased) and it should not be hard to maintain a
non-systemd boot on Arch even in the long-run. However, someone has to
do the work.

NOTE: Please let's keep any replies on-topic. This is NOT about
whether or not sysvinit or systemd is good or bad.

Testing
=====

This has been repeated a lot, but I think it makes sense to say it
again: We are quickly running out of people who do early testing of
initscripts. I.e., who follow arch-projects, review patches and test
initscripts-git. At some point we will probably also struggle with a
lack of developers/TU's testing initscripts in [testing], so if you
feel passionately about a non-systemd boot on Arch, please join
arch-projects and help with testing.

Initscripts
======

Initscripts are currently fully supported and actively developed. Work
has been going on for a long time to make initscripts and systemd
share the same configuration file format wherever that makes sense,
and this work is mostly completed (at least on the initscripts side).
Moreover, code is shared between systemd and initscripts wherever
possible (there might still be more opportunities for this, but the
work is mostly completed). Together, these two developments should
make it relatively easy to maintain initscripts for Arch in the
long-run, even with a small user/developer base.

I intend to maintain initscripts in the official repos as long as this
makes sense. However, for this to be viable, I think we would need at
least one capable and active initscripts developer who is interested
in helping out and who uses sysvinit/initscripts as their main init
system. In the long-run it would make sense for such a person to take
over maintainership of initscripts. Anyone interested, please join
arch-projects and post reviews, suggestions and patches :-)

Packages requiring systemd
=================

In the (near) future, we expect some packages to no longer support
non-systemd boot. In particular I'm thinking of polkit, networkmanager
and some gnome packages (I don't know which as I don't use gnome
myself). There will probably be more in the future. We might also drop
ConsoleKit from the repos at some point in the future.

No need to panic though. The number of packages that will actually be
need to be rebuilt to support non-systemd boot are actually very
limited (certainly less than ten). An alternative repository just
providing the relevant packages could very easily be maintained by one
committed person (possibly even the same person that will help out
with initscripts). I would be happy to help with getting this started
if anyone is interested.

A point to keep in mind is that the people who don't want to switch to
systemd, might not be using ConsoleKit, polkit, etc anyway, so maybe
this problem is not actually a real one.

rc scripts
=====

Currently we have a few hundred rc scripts in our repos (the scripts
under /etc/rc.d/) shipped with our various packages. This will
probably not change in the near future, but if for whatever reason
some packagers decide to drop some rc scripts from their packages (and
rely purely on the systemd unit files), then it would be very simple
to pull the relevant scripts from our repos and ship them in a
rc-scripts package in the above suggested repository.

Concluding remarks
============

As I have tried to outline above, the amount of work required for a
non-systemd boot is really small, and I'd be happy to help anyone who
decides to take it on. However, I have seen some suggestions of ways
of avoiding systemd that entails splitting the systemd package up,
rebuilding tens of packages just to avoid a systemd-libs dependency or
re-duplicate all the code shared between initscripts and systemd.
This, in my humble opinion, is not worth the effort and is not
something I'd be interested in getting involved with.

Please direct any technical discussions to arch-projects@archlinux.org.

Cheers,

Tom
 
Old 09-27-2012, 01:48 PM
Tom Gundersen
 
Default The future of sysvinit in Arch: Call for Help

Hi guys,

As the move to systemd is under way, and we will soon have packages in
our repos that require your system to be booted with systemd, I
thought this would be a good time to summarize the state of
sysvinit/initscripts in Arch and their future.

Abstract: I think the current state is relatively good (but I'm
clearly very biased) and it should not be hard to maintain a
non-systemd boot on Arch even in the long-run. However, someone has to
do the work.

NOTE: Please let's keep any replies on-topic. This is NOT about
whether or not sysvinit or systemd is good or bad.

Testing
=====

This has been repeated a lot, but I think it makes sense to say it
again: We are quickly running out of people who do early testing of
initscripts. I.e., who follow arch-projects, review patches and test
initscripts-git. At some point we will probably also struggle with a
lack of developers/TU's testing initscripts in [testing], so if you
feel passionately about a non-systemd boot on Arch, please join
arch-projects and help with testing.

Initscripts
======

Initscripts are currently fully supported and actively developed. Work
has been going on for a long time to make initscripts and systemd
share the same configuration file format wherever that makes sense,
and this work is mostly completed (at least on the initscripts side).
Moreover, code is shared between systemd and initscripts wherever
possible (there might still be more opportunities for this, but the
work is mostly completed). Together, these two developments should
make it relatively easy to maintain initscripts for Arch in the
long-run, even with a small user/developer base.

I intend to maintain initscripts in the official repos as long as this
makes sense. However, for this to be viable, I think we would need at
least one capable and active initscripts developer who is interested
in helping out and who uses sysvinit/initscripts as their main init
system. In the long-run it would make sense for such a person to take
over maintainership of initscripts. Anyone interested, please join
arch-projects and post reviews, suggestions and patches :-)

Packages requiring systemd
=================

In the (near) future, we expect some packages to no longer support
non-systemd boot. In particular I'm thinking of polkit, networkmanager
and some gnome packages (I don't know which as I don't use gnome
myself). There will probably be more in the future. We might also drop
ConsoleKit from the repos at some point in the future.

No need to panic though. The number of packages that will actually be
need to be rebuilt to support non-systemd boot are actually very
limited (certainly less than ten). An alternative repository just
providing the relevant packages could very easily be maintained by one
committed person (possibly even the same person that will help out
with initscripts). I would be happy to help with getting this started
if anyone is interested.

A point to keep in mind is that the people who don't want to switch to
systemd, might not be using ConsoleKit, polkit, etc anyway, so maybe
this problem is not actually a real one.

rc scripts
=====

Currently we have a few hundred rc scripts in our repos (the scripts
under /etc/rc.d/) shipped with our various packages. This will
probably not change in the near future, but if for whatever reason
some packagers decide to drop some rc scripts from their packages (and
rely purely on the systemd unit files), then it would be very simple
to pull the relevant scripts from our repos and ship them in a
rc-scripts package in the above suggested repository.

Concluding remarks
============

As I have tried to outline above, the amount of work required for a
non-systemd boot is really small, and I'd be happy to help anyone who
decides to take it on. However, I have seen some suggestions of ways
of avoiding systemd that entails splitting the systemd package up,
rebuilding tens of packages just to avoid a systemd-libs dependency or
re-duplicate all the code shared between initscripts and systemd.
This, in my humble opinion, is not worth the effort and is not
something I'd be interested in getting involved with.

Please direct any technical discussions to arch-projects@archlinux.org.

Cheers,

Tom
 
Old 09-27-2012, 04:46 PM
"Ralf Mardorf"
 
Default The future of sysvinit in Arch: Call for Help

Hi Tom,

I had no time to read the complete mail, I'll do it ASAP.
Is it possible to configure pacman to upgrade initscripts and related
packages only from testing, but no other packages?


Regards,
Ralf
 
Old 09-27-2012, 05:03 PM
Tom Gundersen
 
Default The future of sysvinit in Arch: Call for Help

On Thu, Sep 27, 2012 at 6:46 PM, Ralf Mardorf
<ralf.mardorf@alice-dsl.net> wrote:
> Is it possible to configure pacman to upgrade initscripts and related
> packages only from testing, but no other packages?

I don't think you can make pacman do that automatically (I think not).
What you can do is add [testing] as your last repository in
pacman.conf and install initscripts from there manually:

$ pacman -S testing/initcripts

You'll have to know when to do this though, as you won't get a
notification when a new version hits testing. (NOTE: in general, this
sort of cherry-picking from testing is discouraged as you might have
out-of-date dependencies).

What I do is to create an initscripts-git package and install that
instead (obviously this is a lot more bleeding edge than [testing]):

$ git clone git://projects.archlinux.org/initscripts.git
$ cd initscripts
$ makepkg
$ pacman -U initscripts-git-20120927-c67d598-any.pkg.tar.xz

Cheers,

Tom
 
Old 09-27-2012, 08:22 PM
Eric Bélanger
 
Default The future of sysvinit in Arch: Call for Help

On Thu, Sep 27, 2012 at 9:48 AM, Tom Gundersen <teg@jklm.no> wrote:
> Hi guys,
>
> As the move to systemd is under way, and we will soon have packages in
> our repos that require your system to be booted with systemd, I
> thought this would be a good time to summarize the state of
> sysvinit/initscripts in Arch and their future.
>
> Abstract: I think the current state is relatively good (but I'm
> clearly very biased) and it should not be hard to maintain a
> non-systemd boot on Arch even in the long-run. However, someone has to
> do the work.
>
> NOTE: Please let's keep any replies on-topic. This is NOT about
> whether or not sysvinit or systemd is good or bad.
>

> Initscripts
> ======
>
> Initscripts are currently fully supported and actively developed. Work
> has been going on for a long time to make initscripts and systemd
> share the same configuration file format wherever that makes sense,
> and this work is mostly completed (at least on the initscripts side).
> Moreover, code is shared between systemd and initscripts wherever
> possible (there might still be more opportunities for this, but the
> work is mostly completed). Together, these two developments should
> make it relatively easy to maintain initscripts for Arch in the
> long-run, even with a small user/developer base.
>
> I intend to maintain initscripts in the official repos as long as this
> makes sense. However, for this to be viable, I think we would need at
> least one capable and active initscripts developer who is interested
> in helping out and who uses sysvinit/initscripts as their main init
> system. In the long-run it would make sense for such a person to take
> over maintainership of initscripts. Anyone interested, please join
> arch-projects and post reviews, suggestions and patches :-)
>

Hi,

I'm a bit confused by this post. My understanding was that we were
switching to systemd as the default init system because maintaining
two init systems was too much work and problems. Therefore, I thought
that it was implied that once systemd is the default, we would stop
supporting initscripts.

I agree that we should keep supporting initscripts for a short
transition period (1 month?) after systemd is the default. If we do
things this way, we should decide on the length so we could mention it
in the "systemd is now default" announcement. After that transition
period, we should drop support for initscript which means:

-remove initscripts from the repos
-no more developement in git and on arch-project ML
-we can start removing rc.d scripts from packages as we update them

If there is user interest, they can clone the git repo and continue
developpement on github or on another one of these open source
website. And AUR can host the PKGBUILD for initscript and a collection
of the rc.d scripts. By letting initscripts become a user project,
we will be able to use our resource on other aspects of the distro.

Also maintaining initscripts in repo also means maintaining the rc.d
scripts. As most of us dev/TU are using (or will use) systemd, these
will be harder to maintain and fix.

I don't know what you think about this but that's how I see things.

Eric
 
Old 09-27-2012, 09:11 PM
Fons Adriaensen
 
Default The future of sysvinit in Arch: Call for Help

On Thu, Sep 27, 2012 at 03:48:06PM +0200, Tom Gundersen wrote:

> I intend to maintain initscripts in the official repos as long as this
> makes sense. However, for this to be viable, I think we would need at
> least one capable and active initscripts developer who is interested
> in helping out and who uses sysvinit/initscripts as their main init
> system. In the long-run it would make sense for such a person to take
> over maintainership of initscripts. Anyone interested, please join
> arch-projects and post reviews, suggestions and patches :-)

A question about this: apart from changes such as those required
to accomodate systemd or the /lib to /usr/lib migration, _what_ is
actually involved in the day-to-day maintenance of initscripts ?
In other words, what sort of events would mean they need to be
modified ?

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
 
Old 09-27-2012, 09:30 PM
Tom Gundersen
 
Default The future of sysvinit in Arch: Call for Help

On Thu, Sep 27, 2012 at 10:22 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
> I'm a bit confused by this post.

I guess I should clarify my aim: As there are vocal proponents of
sysvinit who feel strongly about staying with that, I'd rather help
them get started in the right direction rather than cause lots of
unnecessary confusion and fragmentation (as I alluded to at the end of
my email I have seen some misguided attempts at doing this which I
think would be detrimental to everyone). Where this work happens (if
it happens), is not really anything I gave much thought. If it is the
consensus that we should quickly drop initscripts and sysvinit from
our repos and ask people to work on it elsewhere that's completely
fine with me.

> My understanding was that we were
> switching to systemd as the default init system because maintaining
> two init systems was too much work and problems.

My take is that it would be too much trouble to make all packages
(polkit, networkmanager, gnome, ...) support both running under
initscripts and systemd. Moreover, it is not really possible to
improve initscripts to the point where it is competitive to systemd.
So making systemd the default makes sense.

However, maintaining the initscripts package as it currently is is not
really a big problem from a technical point of view. Nor is
maintaining non-systemd versions of the relevant packages in a
separate repo.

> -remove initscripts from the repos
> -no more developement in git and on arch-project ML

I don't see the benefit of doing that quickly, but if that's what you
guys want, it is fine with me. I would be in favor of initscripts
dying a natural death.

> -we can start removing rc.d scripts from packages as we update them

That would be fine (and someone could gather them from svn and put
them in a package in some third-party repo (as I suggested)).

> By letting initscripts become a user project,
> we will be able to use our resource on other aspects of the distro.

I'm not suggesting that anyone but me should put any efforts at all
towards supporting non-systemd systems. My point was exactly to get a
user-driven project started (if anyone steps up).

> Also maintaining initscripts in repo also means maintaining the rc.d
> scripts.

I don't think that follows. In the same way that systemd has been in
community/extra/core for a long time without service files around, the
same could be the case for initscripts.

> As most of us dev/TU are using (or will use) systemd, these
> will be harder to maintain and fix.

I agree, rc scripts should be dropped as soon as they become a burden
(which could be decided on a package-by-package basis).

> I don't know what you think about this but that's how I see things.

Sorry if I created any confusion. Hope it is clear now.

-t
 
Old 09-27-2012, 09:34 PM
Tom Gundersen
 
Default The future of sysvinit in Arch: Call for Help

On Thu, Sep 27, 2012 at 11:11 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
> A question about this: apart from changes such as those required
> to accomodate systemd or the /lib to /usr/lib migration, _what_ is
> actually involved in the day-to-day maintenance of initscripts ?
> In other words, what sort of events would mean they need to be
> modified ?

Bugs. Changes to related packages (mkinitcpio, udev, lvm, mdadm,
cryptsetup, util-linux, filesystem). You'd probably want to maintain
compat with the systemd config files (so you'd not also need to
duplicate all the documentation/wiki) so whenever they are extended
support should probably be added to initscripts (as we now use the
systemd tools this might be a rare occurrence).

In short: One would just have to make sure to avoid general bit-rot as
with any software.

-t
 
Old 09-27-2012, 11:39 PM
"G. Schlisio"
 
Default The future of sysvinit in Arch: Call for Help

-remove initscripts from the repos
-no more developement in git and on arch-project ML

I don't see the benefit of doing that quickly, but if that's what you
guys want, it is fine with me. I would be in favor of initscripts
dying a natural death.



some people are stuck with initscripts for a while, letting it die
naturally would be great for such usecases.
i am running an arch server in a virtual private server where can not
change the kernel and depend on my provider.

i am quite sure, there are others around too.
 
Old 09-27-2012, 11:40 PM
Daniel Wallace
 
Default The future of sysvinit in Arch: Call for Help

"G. Schlisio" <g.schlisio@gmx.de> wrote:

>>> -remove initscripts from the repos
>>> -no more developement in git and on arch-project ML
>> I don't see the benefit of doing that quickly, but if that's what you
>> guys want, it is fine with me. I would be in favor of initscripts
>> dying a natural death.
>>
>
>some people are stuck with initscripts for a while, letting it die
>naturally would be great for such usecases.
>i am running an arch server in a virtual private server where can not
>change the kernel and depend on my provider.
>i am quite sure, there are others around too.

If you are running on openvz you could always just switch to another init. Runit is what I am using on mine, it is really easy to write your own services for it.
 

Thread Tools




All times are GMT. The time now is 01:11 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org