Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: Re: eselect init
Date: Sat, 08 Jun 2013 13:38:37
Message-Id: 20130608133754.GB7422@rathaus.eclipse.co.uk
In Reply to: Re: [gentoo-dev] Re: Re: eselect init by Fabio Erculiani
1 On Sun, Jun 02, 2013 at 08:48:23PM +0200, Fabio Erculiani wrote:
2 > On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long
3 > <slong@××××××××××××××××××.uk> wrote:
4 > >
5 >
6 > [...]
7 >
8 > > The whole symlink/boot/fallback thing is simply a waste of technical effort.
9 > > And blanket "your opinion" and "you didn't comment a week ago, so I don't
10 > > have to deal with the substance of your points" don't change that.
11 >
12 > Waste? We have multiple use cases for that as stated in several places
13 > (here, bugzilla, IRC, etc).
14 > If such use cases are of no interest for you, then you shouldn't be bothered.
15
16 The specific idea of reimplementing the kernel fallback mechanism is a waste of
17 technical effort. Not the whole idea of eselect init, as I stated several times.
18
19 If you lose that idiotic idea, you have a lot less complexity to worry about and
20 can instead get on with the *necessary* complexity: handling whether it is safe
21 to switch boot, and how to make it so given the 'from' init and the 'to' init,
22 which might require write access to the rootfs, eg to swap inittab, or to
23 mkdir -p a necessary path.
24
25 It could need anything, there's simply no way of knowing, and it will require
26 maintenance over time as init-systems change. That's why the Unix inventors came
27 up with sh. And the best people to maintain it over time, are the users in
28 collaboration with the init-system devs, since they are the ones who have the
29 testcases in front of them, and the motivation to make the software work. While
30 the devs have a broader view, and an interest in keeping things portable (aka:
31 'generic'.)
32
33 Please try to read and consider my whole argument, instead of selectively quoting
34 one part and using it to justify YAF ad-hominem.
35
36 --
37 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)