[gentoo-dev] Re: Re: Re: eselect init

[Steven J. Long]

On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote:
> On 06/02/2013 08:20 PM, Steven J. Long wrote:
> > On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
> >> On 06/01/2013 11:23 AM, Steven J. Long wrote:
> >>> That's not an argument for using a symlink switcher or the
> >>> equivalent across the board, by any means.
> >>
> >> Your opinion.
> >
> > That's not an argument for it either.
>
> Had been explained in the thread, please read it.

..
> Again you should read the whole thread, please do, the whole eselect
> init stuff should stay opt-in for the time being so all this discussion
> is close to pointless.

Actually the point is how to implement the best solution in Gentoo, which is
the point of this mailing-list. To float ideas and see what other perspectives
can contribute to the design. For instance, I think Duncan's idea of a single
mode, effectively secondary bootloader, is the only thing that makes any sense.

It's a Gentoo-specific init-switcher that only runs when the user has initiated
a switchover.

Implementing an init fallback is unneeded, since the kernel tries so many paths
already. And Duncan's mail is at least about the interesting, and *useful* part:
making the system ready to switch, and a setup for init-system switching as a
whole.

Including write to rootfs, eg to change inittab format.

> Consider this email a friendly warning, please do not pollute the Gentoo
> media with pointless email when you had been already politely told that
> your concern had been addressed in the previous email in the thread.

No you weren't polite. You wrote an email that had zero technical content in
it and that was basically just 'ad-hominem' as has been pointed out to me:

http://www.netbooknews.com/wp-content/2011/07/the-pyramid-of-debate-550x417.jpg

Review your last email in the context of the above, please.
 
> > You're free to work on whatever you want. You just haven't made any
> > case for why the rest of the ecosystem should be crippled to allow for a
> > use-case that would be better served by an existing, far more robust
> > solution.
>
> Had it been the case we wouldn't had spent some weeks picking our brains
> on it.

Yes because programmers never make mistakes, and humans are so good at separating
the woods from the trees..

> > Then it can be runit or whatever else takes your fancy. You are ignoring
> > the point of that paragraph though: someone has to put the install together.
> >
> > Or it isn't a Gentoo install.
>
> And you seem to miss the point that all you are telling had been
> discussed, taken in consideration and in some part agreed with already...

Lala. Someone puts the install together: they run (or their script runs):
mv /sbin/init /bin/init && mv /sbin/einit || error 'unable to setup init'

> > Wrt to the first, funnily enough the kernel developers have been here before,
> > just like they had with ethN and wlanN. It's a basic requirement for developing
> > an OS that you be able to switch init and fallback to other options.
>
> Again you didn't ready or you forgot. I said already I don't care about
> systemd many times, yet you failed to remember that.
> My specific use-case would require a trip to single mode and a second
> reboot, the way I want to do spares that.

Actually none of this has got anything to do with systemd, nor did I mention it, 
so please stop banging on about your feelings about it. They're not relevant to
this discussion, since it's init-system agnostic, just like the kernel fallback
mechanism is, or there's no point to it.
 
> On an EFI-stub only system it would require at least a kernel rebuild or
> a trip to the efi shell if available.

No it wouldn't, see above. And http://marc.info/?l=gentoo-dev&m=136968639518816&w=2
 
> > Honestly, my goal is a saving of time so people can focus on making the
> > eselect module work properly, and be of real value to an end-user who wants
> > to switch init.
>
> To not make this a waste of time here a summary of the whole thing:

Ah finally some technical content. Yes, the above was a waste of time, and so
was your last email. Just a friendly reminder.

> - eselect init will be opt-in for the time being, people can be left on
> their own tools if the want it

Yes, but we want a sane and robust implementation in Gentoo, irrespective of
who's using it.

> - the default init will stay sysvinit. Discussion ongoing if is better
> to have it installed in a secondary fallback path is open (e.g. /bin/init).

You mean "use the kernel fallback mechanism"? I'm sure you won't be surprised
to hear I think that's a good idea.

> - I still need to send patches to busybox and sysvinit upstream to add a
> command line switch to locate the inittab.

Sounds good. busybox using the standard location with a non-standard format
sounds like a mistake though, at least for the default Gentoo config, where
it is supposed to live alongside the normal Linux utils.  When the user has
a saved-config, it is of course up to them what happens.

> - people wanting to switch init or enable/disable init addons using
> eselect init might have to refer to /sbin/einit or such custom path
> (assuming we fail to come to an agreement regarding /bin/init)
>
> The wrapper in /sbin/init is mostly needed to get to the point of a
> clean reboot.

I think Duncan's idea makes a lot of sense. It'd be easy enough to write the
base framework to use sh modules, which users and init-system devs collaborate
on, and users maintain effectively over time, by sending in bug-reports and
patches. The existing openrc codebase could be used as a starting point.
 
> The first time you boot on a new system it is executed picking the new
> init and just that.
>
> For addons such as bootchart2 and e4rat it would do slightly more.
>
> Assuming upstream doesn't accept custom paths for the inittab, for my
> specific usecase I might bake something that would remount r/w and pivot
> the inittabs.

Or build that in as part of the design, as Duncan raised.
 
> Anybody willing to do something more extreme could even consider having
> /sbin/init as a symlink and have the boot-time configuration switch the
> symlink, thus making the whole script run just a single boot per switch.
>
> Not necessary but surely feasible.

Many things are doable. Many less are advisable. 

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)