Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#826205: Please move /lib/init/{vars.sh,init-d-script} to sysv-rc
6 views
Skip to first unread message
Martin Pitt
Jun 3, 2016, 6:10:03 AM6/3/16
to
Package: sysv-rc
Version: 2.88dsf-59.4
Hello,
There is an ongoing effort to make fewer of sysvinit's binary packages
essential and even install by default, as most bits are not needed
under systemd.
In particular, we are really close to dropping initscripts from the
"Priority: required" set (in fact, it already dropped out of the
default install in the current Ubuntu development release). All of its
shipped init scripts have native systemd units and thus are not
needed. The only thing that we still need is /lib/init/vars.sh as
quite a lot of init scripts [1] source this unconditionally. Petter
Reinholdtsen said [2] that this file is to be considered official API
for init.d scripts, so as long as we still have packages which only
ship a SysV init script (i. e., many many years), we have to keep
this.
Also, we are close to dropping sysvinit-utils from required/essential.
pidof should move to procps [3], and the very few packages that
actually use killall5 and fstab-decode could just grow a dependency on
it.
Thus I think we should consider keeping sysv-rc as the package that
provides the basic infrastructure for SysV init scripts (/etc/rc?.d/
structure and /lib/init/{vars.sh,init-d-script}), and keep only that
as required/Essential. Thus these two files should move there.
Some of its dependency should also move, e. g. startpar is only
needed for initscripts [4]. Ideally insserv could be moved to
initscripts as well, but I haven't done research yet whether that
would still be "necessary infrastructure to keep SysV init scripts
working" (I have a hunch that this is the case, as something needs to
create /etc/rc?.d/ links for packages that only have SysV init
scripts, under any init system).
So I'll prepare a patch for moving these two files, and another git
patch for [4], and I'd like to NMU this unless you have objections.
Thanks for considering,
Martin
[1] https://codesearch.debian.net/perpackage-results/lib/init/vars.sh
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710519#20
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810018
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825937
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Version: 2.88dsf-59.4
Hello,
There is an ongoing effort to make fewer of sysvinit's binary packages
essential and even install by default, as most bits are not needed
under systemd.
In particular, we are really close to dropping initscripts from the
"Priority: required" set (in fact, it already dropped out of the
default install in the current Ubuntu development release). All of its
shipped init scripts have native systemd units and thus are not
needed. The only thing that we still need is /lib/init/vars.sh as
quite a lot of init scripts [1] source this unconditionally. Petter
Reinholdtsen said [2] that this file is to be considered official API
for init.d scripts, so as long as we still have packages which only
ship a SysV init script (i. e., many many years), we have to keep
this.
Also, we are close to dropping sysvinit-utils from required/essential.
pidof should move to procps [3], and the very few packages that
actually use killall5 and fstab-decode could just grow a dependency on
it.
Thus I think we should consider keeping sysv-rc as the package that
provides the basic infrastructure for SysV init scripts (/etc/rc?.d/
structure and /lib/init/{vars.sh,init-d-script}), and keep only that
as required/Essential. Thus these two files should move there.
Some of its dependency should also move, e. g. startpar is only
needed for initscripts [4]. Ideally insserv could be moved to
initscripts as well, but I haven't done research yet whether that
would still be "necessary infrastructure to keep SysV init scripts
working" (I have a hunch that this is the case, as something needs to
create /etc/rc?.d/ links for packages that only have SysV init
scripts, under any init system).
So I'll prepare a patch for moving these two files, and another git
patch for [4], and I'd like to NMU this unless you have objections.
Thanks for considering,
Martin
[1] https://codesearch.debian.net/perpackage-results/lib/init/vars.sh
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710519#20
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810018
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825937
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Petter Reinholdtsen
Jun 3, 2016, 6:30:02 AM6/3/16
to
No objections from my part, as I do not have all the required details in
my head any more, just want to clear up something that look like
misunderstandings.
[Martin Pitt]
> Some of its dependency should also move, e. g. startpar is only
> needed for initscripts [4]. Ideally insserv could be moved to
> initscripts as well, but I haven't done research yet whether that
> would still be "necessary infrastructure to keep SysV init scripts
> working" (I have a hunch that this is the case, as something needs to
> create /etc/rc?.d/ links for packages that only have SysV init
> scripts, under any init system).
'startpar' is not really needed for scripts in the initscripts package.
> needed for initscripts [4]. Ideally insserv could be moved to
> initscripts as well, but I haven't done research yet whether that
> would still be "necessary infrastructure to keep SysV init scripts
> working" (I have a hunch that this is the case, as something needs to
> create /etc/rc?.d/ links for packages that only have SysV init
> scripts, under any init system).
'startpar' is an implementation detail behind the code in /etc/init.d/rc
and /etc/init.d/rcS which belong to the sysv-rc package. The
implementation detail is to run the init.d scripts in parallell using
the dependency information stored in /etc/init.d/.depend.* (generated by
insserv).
And 'insserv' is not really needed for the initscripts scripts either.
It is the internal implementation for the sysv-rc way of starting init.d
scripts called by /usr/sbin/update-rc.d from the init-system-helpers
package.
So update-rc.d require insserv when /etc/init.d/rc from sysv-rc is used,
and /etc/init.d/rc require startpar to run scripts in parallell.
Do your proposal still make sense when those details are the way they
are? I'm not sure using the initscripts package as a resting place for
things that is no longer needed with systemd is a good idea. After all,
the initscripts scripts work just fine with file-rc and no parallel
boot, and in that use case startpar isn't used.
The key platforms in Debian using sysvinit/initscripts/sysv-rc these
days are Hurd and kFreeBSD. Perhaps someone from those platforms should
test the new proposal to ensure it do not break their installation and
boot?
--
Happy hacking
Petter Reinholdtsen
Martin Pitt
Jun 3, 2016, 7:10:02 AM6/3/16
to
Hello Petter,
Petter Reinholdtsen [2016-06-03 12:22 +0200]:
> [Martin Pitt]
> > Some of its dependency should also move, e. g. startpar is only
> > needed for initscripts [4]. Ideally insserv could be moved to
> > initscripts as well, but I haven't done research yet whether that
> > would still be "necessary infrastructure to keep SysV init scripts
> > working" (I have a hunch that this is the case, as something needs to
> > create /etc/rc?.d/ links for packages that only have SysV init
> > scripts, under any init system).
>
> 'startpar' is not really needed for scripts in the initscripts package.
> 'startpar' is an implementation detail behind the code in /etc/init.d/rc
> and /etc/init.d/rcS which belong to the sysv-rc package.
Indeed, sorry for the typo there. I indeed meant sysv-rc, my replies
to https://bugs.debian.org/825937 have the right package name.
My initial reaction was to move the startpar dependency to
sysvinit-core (and make it a recommends), as /etc/init.d/rc gets along
fine without startpar and you only really need it if you actually run
SysV init. But as file-rc and openrc depend on sysvinit-core, but
replace sysv-rc, then the current status quo is to install it under
systemd (where it's useless), or to move the dep to sysvinit-core and
install it under openrc/file-rc (where it's equally useless, but at
least for a much smaller user base).
> And 'insserv' is not really needed for the initscripts scripts either.
> It is the internal implementation for the sysv-rc way of starting init.d
> scripts called by /usr/sbin/update-rc.d from the init-system-helpers
> package.
Right, hence my thought that we can't drop this from the default
install just yet.
> Do your proposal still make sense when those details are the way
> they are?
Indeed it doesn't. The init systems have mutually exclusive
dependencies:
sysvinit-core "pure": sysv-rc, sysvinit-utils, startpar
openrc/file-rc: sysvinit-utils, sysvinit-core
systemd: sysv-rc
So AFAIK the main issue is that sysvinit does not have a "base files"
kind of package that is required and ships vars.sh/init-d-helpers.
Having them in sysvinit-utils and sysv-rc keeps these packages forever
at "Priority: required".
One possible step to relax that maze of dependencies would be to make
update-rc.d not depending on insserv and pre-existing /etc/rc?.d/
directories any more, but create the directories on the fly and fall
back to creating symlinks with a static priority under systemd (as
that doesn't care about the priority anyway, just whether it's enabled
or not). But we still need a place that ships vars.sh and
init-d-script, as a lot of packages use them without depending on
them.
So the part from this proposal/my current patch that remains valid is
to move vars.sh out of initscripts. We are one procps upload away from
dropping initscripts out of the default install, and initscripts is by
far the biggest package. AFAICS we could move this to sysvinit-utils
for now without breaking any of openrc/file-rc/sysvinit-core/systemd.
Thanks,
Martin
Petter Reinholdtsen [2016-06-03 12:22 +0200]:
> No objections from my part, as I do not have all the required details in
> my head any more, just want to clear up something that look like
> misunderstandings.
Thanks for your followup! This indeed raised an important issue.
> my head any more, just want to clear up something that look like
> misunderstandings.
> [Martin Pitt]
> > Some of its dependency should also move, e. g. startpar is only
> > needed for initscripts [4]. Ideally insserv could be moved to
> > initscripts as well, but I haven't done research yet whether that
> > would still be "necessary infrastructure to keep SysV init scripts
> > working" (I have a hunch that this is the case, as something needs to
> > create /etc/rc?.d/ links for packages that only have SysV init
> > scripts, under any init system).
>
> 'startpar' is not really needed for scripts in the initscripts package.
> 'startpar' is an implementation detail behind the code in /etc/init.d/rc
> and /etc/init.d/rcS which belong to the sysv-rc package.
to https://bugs.debian.org/825937 have the right package name.
My initial reaction was to move the startpar dependency to
sysvinit-core (and make it a recommends), as /etc/init.d/rc gets along
fine without startpar and you only really need it if you actually run
SysV init. But as file-rc and openrc depend on sysvinit-core, but
replace sysv-rc, then the current status quo is to install it under
systemd (where it's useless), or to move the dep to sysvinit-core and
install it under openrc/file-rc (where it's equally useless, but at
least for a much smaller user base).
> And 'insserv' is not really needed for the initscripts scripts either.
> It is the internal implementation for the sysv-rc way of starting init.d
> scripts called by /usr/sbin/update-rc.d from the init-system-helpers
> package.
install just yet.
> Do your proposal still make sense when those details are the way
> they are?
dependencies:
sysvinit-core "pure": sysv-rc, sysvinit-utils, startpar
openrc/file-rc: sysvinit-utils, sysvinit-core
systemd: sysv-rc
So AFAIK the main issue is that sysvinit does not have a "base files"
kind of package that is required and ships vars.sh/init-d-helpers.
Having them in sysvinit-utils and sysv-rc keeps these packages forever
at "Priority: required".
One possible step to relax that maze of dependencies would be to make
update-rc.d not depending on insserv and pre-existing /etc/rc?.d/
directories any more, but create the directories on the fly and fall
back to creating symlinks with a static priority under systemd (as
that doesn't care about the priority anyway, just whether it's enabled
or not). But we still need a place that ships vars.sh and
init-d-script, as a lot of packages use them without depending on
them.
So the part from this proposal/my current patch that remains valid is
to move vars.sh out of initscripts. We are one procps upload away from
dropping initscripts out of the default install, and initscripts is by
far the biggest package. AFAICS we could move this to sysvinit-utils
for now without breaking any of openrc/file-rc/sysvinit-core/systemd.
Thanks,
Martin
Martin Pitt
Jun 3, 2016, 6:40:02 PM6/3/16
to
Control: retitle -1 Please move /lib/init/vars.sh to sysvinit-utils
Control: tag -1 patch
Hello again,
Martin Pitt [2016-06-03 13:01 +0200]:
Control: tag -1 patch
Hello again,
Martin Pitt [2016-06-03 13:01 +0200]:
> So the part from this proposal/my current patch that remains valid is
> to move vars.sh out of initscripts. We are one procps upload away from
> dropping initscripts out of the default install, and initscripts is by
> far the biggest package. AFAICS we could move this to sysvinit-utils
> for now without breaking any of openrc/file-rc/sysvinit-core/systemd.
Attached git formatted patch does that.
> to move vars.sh out of initscripts. We are one procps upload away from
> dropping initscripts out of the default install, and initscripts is by
> far the biggest package. AFAICS we could move this to sysvinit-utils
> for now without breaking any of openrc/file-rc/sysvinit-core/systemd.
Martin Pitt
Jun 8, 2016, 9:40:03 AM6/8/16
to
Martin Pitt [2016-06-04 0:30 +0200]:
I'll push the release changelog/tag to git too.
> Attached git formatted patch does that.
I pushed this to git now, and NMUed to DELAYED/5. If/when this lands,
I'll push the release changelog/tag to git too.
0 new messages