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

[Luca Barbato]

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.

>>> Firstly, we should be recommending people install Gentoo with enough
>>> flexibility to configure and use their system how they choose. In the
>>> UEFI arena, why not simply recommend something like rEFIt instead of
>>> making everyone go through a load of development effort, to restrict
>>> us all to a crippled use-case?
>>
>> Beside rEFIt being deprecated and rEFInd being in early stage of
>> development (thus working great on some platforms and not working at all
>> on some other) and with a good chunk of documentation to read before
>> being able of deploying it?
>
> The typical thing Gentoo users get told is "this is a new thing, it will
> take some time to work out, bear with us" as their production servers go
> tits-up around them. So in this case too, work with upstream to implement
> better solutions you, and the wider ecosystem, can all use.

I'm afraid you never used those nor you are in one of those situation in
which you have less options.

> And STILL the best interim solution till your EFI setup has a bootloader.

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.

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.

> 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.

> 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...

> 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.

On an EFI-stub only system it would require at least a kernel rebuild or
a trip to the efi shell if available.

> 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:

- eselect init will be opt-in for the time being, people can be left on
their own tools if the want 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).
- I still need to send patches to busybox and sysvinit upstream to add a
command line switch to locate the inittab.
- 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.

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.

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.

lu