tags 575080 + patch
thanks
[Chanoch (Ken) Bloom]
> There's a third option, now that I look more in detail at your other
> maintainer scripts. sysv-rc.preinst touches
> /etc/init.d/.legacy-bootordering on upgrade (under certain
> circumstances), but doesn't create it on install. You add tests to
> create the /etc/init.d/.legacy-bootordering file on install too,
> based on appropriate circumstances.
Actually, this almost the same as my second approach. I've commited
this patch to svn, which I believe will solve this migration issue.
Index: debian/sysv-rc.postinst
===================================================================
--- debian/sysv-rc.postinst (revision 1898)
+++ debian/sysv-rc.postinst (working copy)
@@ -172,6 +172,19 @@
fi
rm /var/run/sysv-rc.upgrade
fi
+
+ # Detect migrations away from file-rc, where the legacy boot
+ # ordering is used but the flag file to indicated legacy boot
+ # ordering is missing. Can not do this in preinst, as preinst
+ # might be executed before the postinst of file-rc creatingthe
+ # files in /etc/rc?.d/.
+ for f in /etc/rc0.d/S* ; do
+ if [ ! -f $flagfile ] && [ -f $f ] ; then
+ touch $flagfile
+ break
+ fi
+ done
+
if [ -f $flagfile ] ; then
# Still using legacy ordering, try to convert
if try_to_convert ; then
> The second approach sounds best to me. It has the least corner cases,
> and sounds the least fragile.
> * In all of the other approaches, you have to think about exactly
> which versions of which init systems need the reordering, and
> exactly how to detect them correctly. There are potentially four
> init systems now -- sysv-rc/insserv, file-rc, upstart and
> systemd (in the near future) -- so that's going to be a lot of
> work in the long run.
Actually, there are less combination. sysv-rc and file-rc two options
running init.d scripts, and upstart is not an alternative to these two
(it is calling /etc/init.d/rc from sysv-rc or file-rc and not running
the init.d scripts directly). systemd might be an alternative to
sysv-rc and file-rc, but the details are not yet known.
> * The only case in which the second approach fails is if there's
> some legitimate reason to start some service in runlevel 0 or 6,
> and you expect to support people who customize their init
> subsystems to specifically undo the change. I think this is
> unlikely.
It is not only unlikely, it is always wrong. Even start symlinks are
called with the stop argument in runlevels 0 and 6, and it has been
like that for a long time.
> * It automatically fixes any system that is already broken by a
> botched file-rc to sysv-rc switch, even if file-rc is no longer
> installed. (None of the other techniques does that.)
Yeah. :)
> That would be strictly a file-rc issue. It can be resolved by purging
> file-rc, or by rewriting file-rc's update script to do something more
> intelligent in this situation.
Yes.
> Actually the bigger question is whether file-rc still makes sense in
> the bootup picture as it stands now. Will file-rc continue to exist
> as we develop all of these fancy new boot systems?
I leave that completely in the hands of the file-rc maintaners and
users. :)
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
