Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

Hello,

Long time no see. Update on the feature request: Michał Górny rejected
Florian's the pull request, raising concerns regarding the use of gentoo
specific tooling;
stating that eselect-repository should work (as I understood it) as a
standalone program.

Originally, Górny suggested updating the repositories.xml file by adding
the masters entry.

That's why I did some data processing of the overlays.
(It turns out only a small set of overlays have additional dependencies
besides gentoo).
With this data now processed, adding the masters entry to the
repositories.xml
should be way easier.
Here's the repo: https://github.com/lima-limon-inc/OverlayStats
(it also contains information regarding package amounts by overlay,
which I found it quite interesting)
And here's a google sheet with the data loaded in:
https://docs.google.com/spreadsheets/d/1Spti8KCFQbi0kszvgBnxMtAlUC3RU1HZU8MZHlYP5xQ/edit?usp=sharing

Having said that, there's still the issue of data duplication that Florian
raised.
That I do not know how could be tackled.

Best regards,
- Tomas Fabrizio Orsi

Re: [gentoo-dev] Eselect repository feature request

[Florian Schmaus]

On 21/06/2023 19.59, TOMAS FABRIZIO ORSI wrote:

I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.

I agree.
I'm glad Flow has their ideas straight.

By the way Flow, could you share the links of the repo/PR so that we can
follow the development along? I would love to see it! ^_^


https://github.com/projg2/eselect-repository/pull/23

Unlike I previously assumed, this currently shells out twice to portage:

1. to query the list of currently available repositories, via "portageq 
get_repos /"

2. to sync a repository, via "emaint sync -r ${repo}"

Feedback welcomed. :)

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Eselect repository feature request

[Sam James]

TOMAS FABRIZIO ORSI  writes:

>  2. Add a way to use the "real" upstream sources instead of our mirrored
>  ones
>
>  
> Isn't this eselect repository's default behaviour? Or am I misunderstanding?
> When I run "eselect repository list" I get the source repositories, not the 
> mirrored ones.
> Is it using the mirrored one behind the scenes?

(Please don't top-post.)

No, it uses the mirrores ones with metadata.

>
> Best regards,
> - Tomas Fabrizio Orsi
> El mié, 21 jun 2023 a las 15:44, Sam James () escribió:
>
>  Florian Schmaus  writes:
>
>  > [[PGP Signed Part:Undecided]]
>  > On 21/06/2023 17.56, Mike Gilbert wrote:
>  >> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus  wrote:
>  >>>
>  >>> On 20.06.23 19:26, Mike Gilbert wrote:
>   On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:
>  >
>  > On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
>  >>   Isn't that duplicating the information of metadata/layout.conf's
>  >>   'master' key-value pair [1]?
>  >>
>  >>
>  >> Yes, I agree that it would be duplicating that information. As a 
> matter
>  >> of fact, Michał Górny pointed the same thing out.
>  >> However, Michał also added, quote: "What's really lacking here is
>  >> support for specifying dependencies via |repositories.xml|
>  >
>  > Do we need to duplicate the information in repositories.xml, with all
>  > the drawbacks of duplication?
>  >
>  > Can't eselect repository add the new repository, then read the 
> 'masters'
>  > value from layout.conf, and add the missing repositories recursively?
>  
>   That would be a significant change in behavior for eselect repository.
>  >>>
>  >>> Right, but it seems to be a desirable behaviour. Cases where the user
>  >>> wants to add a repo but not immediately sync it are probably rare.
>  >>>
>  >>> Furthermore, it would avoid duplicating the information, which avoids
>  >>> the typical drawbacks of duplication (e.g., the two sets getting out of
>  >>> sync).
>  >>>
>  >>> I've looked at the eselect-repository code, and it seems not hard to
>  >>> change the behaviour of "eselect repository add" to add and sync a
>  >>> repository and then, recursively, add and sync further required
>  >>> repositories.
>  >>>
>  >>> I may give it a shot, but ideally I'd know if it has a chance to be
>  >>> accepted upstream first. Or maybe there is a good reason why
>  >>> eselect-repository behaves as it currently does that I am missing?
>  >> I can't speak for "upstream", but here are my concerns:
>  >> 1. As a developer, I might just want to create the repos.conf config
>  >> snippet and sync the repo manually.
>  >> 2. As a user, I might have any arbitrary reason for not wanting to
>  >> sync immediately.
>  >
>  > Would an opt-out switch be enough to alleviate those concerns of you?
>  >
>  >
>  >> 3. eselect-repository does not currently depend on any particular
>  >> package manager. It writes config files intended for Portage, but it
>  >> does not actually invoke any Portage commands. That feels like a
>  >> significant distinction to me.
>  >> 4. If you start invoking Portage commands, you then have to deal with
>  >> the possibility of people using alternate package managers. pkgcore
>  >> can also utilize Portage's repos.conf, and the user might prefer to
>  >> use pmaint instead of emaint or emerge --sync.
>  >
>  > Those two points seem to be based on the same fundamental concern.
>  >
>  > The only portage specific code would be the call to "emaint sync -r
>  > $repo" (remember that "emerge --sync" is just a wrapper for "emaint
>  > sync --auto"). I think it would be easy to add later 1. add support
>  > for different package managers (if the need arises), and 2. make the
>  > "sync command" user configurable.
>
>  While looking at this, it might be worth evaluating 2 other things
>  which users have mentioned during the migration away from layman:
>  1. Adding a way to fully disable the cache fetching;
>  2. Add a way to use the "real" upstream sources instead of our mirrored
>  ones
>
>  best,
>  sam



signature.asc
Description: PGP signature

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> 2. Add a way to use the "real" upstream sources instead of our mirrored
> ones


Isn't this eselect repository's default behaviour? Or am I misunderstanding?
When I run "eselect repository list" I get the source repositories, not the
mirrored ones.
Is it using the mirrored one behind the scenes?

Best regards,
- Tomas Fabrizio Orsi
El mié, 21 jun 2023 a las 15:44, Sam James () escribió:

>
> Florian Schmaus  writes:
>
> > [[PGP Signed Part:Undecided]]
> > On 21/06/2023 17.56, Mike Gilbert wrote:
> >> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus 
> wrote:
> >>>
> >>> On 20.06.23 19:26, Mike Gilbert wrote:
>  On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus 
> wrote:
> >
> > On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> >>   Isn't that duplicating the information of
> metadata/layout.conf's
> >>   'master' key-value pair [1]?
> >>
> >>
> >> Yes, I agree that it would be duplicating that information. As a
> matter
> >> of fact, Michał Górny pointed the same thing out.
> >> However, Michał also added, quote: "What's really lacking here is
> >> support for specifying dependencies via |repositories.xml|
> >
> > Do we need to duplicate the information in repositories.xml, with all
> > the drawbacks of duplication?
> >
> > Can't eselect repository add the new repository, then read the
> 'masters'
> > value from layout.conf, and add the missing repositories recursively?
> 
>  That would be a significant change in behavior for eselect repository.
> >>>
> >>> Right, but it seems to be a desirable behaviour. Cases where the user
> >>> wants to add a repo but not immediately sync it are probably rare.
> >>>
> >>> Furthermore, it would avoid duplicating the information, which avoids
> >>> the typical drawbacks of duplication (e.g., the two sets getting out of
> >>> sync).
> >>>
> >>> I've looked at the eselect-repository code, and it seems not hard to
> >>> change the behaviour of "eselect repository add" to add and sync a
> >>> repository and then, recursively, add and sync further required
> >>> repositories.
> >>>
> >>> I may give it a shot, but ideally I'd know if it has a chance to be
> >>> accepted upstream first. Or maybe there is a good reason why
> >>> eselect-repository behaves as it currently does that I am missing?
> >> I can't speak for "upstream", but here are my concerns:
> >> 1. As a developer, I might just want to create the repos.conf config
> >> snippet and sync the repo manually.
> >> 2. As a user, I might have any arbitrary reason for not wanting to
> >> sync immediately.
> >
> > Would an opt-out switch be enough to alleviate those concerns of you?
> >
> >
> >> 3. eselect-repository does not currently depend on any particular
> >> package manager. It writes config files intended for Portage, but it
> >> does not actually invoke any Portage commands. That feels like a
> >> significant distinction to me.
> >> 4. If you start invoking Portage commands, you then have to deal with
> >> the possibility of people using alternate package managers. pkgcore
> >> can also utilize Portage's repos.conf, and the user might prefer to
> >> use pmaint instead of emaint or emerge --sync.
> >
> > Those two points seem to be based on the same fundamental concern.
> >
> > The only portage specific code would be the call to "emaint sync -r
> > $repo" (remember that "emerge --sync" is just a wrapper for "emaint
> > sync --auto"). I think it would be easy to add later 1. add support
> > for different package managers (if the need arises), and 2. make the
> > "sync command" user configurable.
>
> While looking at this, it might be worth evaluating 2 other things
> which users have mentioned during the migration away from layman:
> 1. Adding a way to fully disable the cache fetching;
> 2. Add a way to use the "real" upstream sources instead of our mirrored
> ones
>
> best,
> sam
>

Re: [gentoo-dev] Eselect repository feature request

[Sam James]

Florian Schmaus  writes:

> [[PGP Signed Part:Undecided]]
> On 21/06/2023 17.56, Mike Gilbert wrote:
>> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus  wrote:
>>>
>>> On 20.06.23 19:26, Mike Gilbert wrote:
 On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:
>
> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
>>   Isn't that duplicating the information of metadata/layout.conf's
>>   'master' key-value pair [1]?
>>
>>
>> Yes, I agree that it would be duplicating that information. As a matter
>> of fact, Michał Górny pointed the same thing out.
>> However, Michał also added, quote: "What's really lacking here is
>> support for specifying dependencies via |repositories.xml|
>
> Do we need to duplicate the information in repositories.xml, with all
> the drawbacks of duplication?
>
> Can't eselect repository add the new repository, then read the 'masters'
> value from layout.conf, and add the missing repositories recursively?

 That would be a significant change in behavior for eselect repository.
>>>
>>> Right, but it seems to be a desirable behaviour. Cases where the user
>>> wants to add a repo but not immediately sync it are probably rare.
>>>
>>> Furthermore, it would avoid duplicating the information, which avoids
>>> the typical drawbacks of duplication (e.g., the two sets getting out of
>>> sync).
>>>
>>> I've looked at the eselect-repository code, and it seems not hard to
>>> change the behaviour of "eselect repository add" to add and sync a
>>> repository and then, recursively, add and sync further required
>>> repositories.
>>>
>>> I may give it a shot, but ideally I'd know if it has a chance to be
>>> accepted upstream first. Or maybe there is a good reason why
>>> eselect-repository behaves as it currently does that I am missing?
>> I can't speak for "upstream", but here are my concerns:
>> 1. As a developer, I might just want to create the repos.conf config
>> snippet and sync the repo manually.
>> 2. As a user, I might have any arbitrary reason for not wanting to
>> sync immediately.
>
> Would an opt-out switch be enough to alleviate those concerns of you?
>
>
>> 3. eselect-repository does not currently depend on any particular
>> package manager. It writes config files intended for Portage, but it
>> does not actually invoke any Portage commands. That feels like a
>> significant distinction to me.
>> 4. If you start invoking Portage commands, you then have to deal with
>> the possibility of people using alternate package managers. pkgcore
>> can also utilize Portage's repos.conf, and the user might prefer to
>> use pmaint instead of emaint or emerge --sync.
>
> Those two points seem to be based on the same fundamental concern.
>
> The only portage specific code would be the call to "emaint sync -r
> $repo" (remember that "emerge --sync" is just a wrapper for "emaint
> sync --auto"). I think it would be easy to add later 1. add support
> for different package managers (if the need arises), and 2. make the
> "sync command" user configurable.

While looking at this, it might be worth evaluating 2 other things
which users have mentioned during the migration away from layman:
1. Adding a way to fully disable the cache fetching;
2. Add a way to use the "real" upstream sources instead of our mirrored
ones

best,
sam


signature.asc
Description: PGP signature

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> I think flow's idea to make the sync command configurable somehow
> would be sufficient, assuming there is demand for it.

I agree.
I'm glad Flow has their ideas straight.

By the way Flow, could you share the links of the repo/PR so that we can
follow the development along? I would love to see it! ^_^

I'm not quite certain what you mean by "module" here, but that sounds
> like unnecessary extra abstraction.
>

I think my line of thought was a bit overkill.
Not to mention that I am not that well versed (if at all)
with portage's implementation detail.

PS: I forgot to mention this in the original email, but I did file a
bug with this feature request. https://bugs.gentoo.org/907959


El mié, 21 jun 2023 a las 14:46, Mike Gilbert ()
escribió:

> On Wed, Jun 21, 2023 at 12:47 PM TOMAS FABRIZIO ORSI 
> wrote:
> > I had not considered that possibility either. In that case, could not
> the overlay
> > dependency resolution be handled as a module?
> > Said module could be a common interface for different package managers.
> > Then, the execution of said module would be handled on a per package
> manager/sync program basis?
>
> I'm not quite certain what you mean by "module" here, but that sounds
> like unnecessary extra abstraction.
>
> I think flow's idea to make the sync command configurable somehow
> would be sufficient, assuming there is demand for it.
>
>

Re: [gentoo-dev] Eselect repository feature request

[Mike Gilbert]

On Wed, Jun 21, 2023 at 12:47 PM TOMAS FABRIZIO ORSI  wrote:
> I had not considered that possibility either. In that case, could not the 
> overlay
> dependency resolution be handled as a module?
> Said module could be a common interface for different package managers.
> Then, the execution of said module would be handled on a per package 
> manager/sync program basis?

I'm not quite certain what you mean by "module" here, but that sounds
like unnecessary extra abstraction.

I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.

Re: [gentoo-dev] Eselect repository feature request

[Mike Gilbert]

On Wed, Jun 21, 2023 at 12:49 PM Florian Schmaus  wrote:
>
> On 21/06/2023 17.56, Mike Gilbert wrote:
> > On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus  wrote:
> >>
> >> On 20.06.23 19:26, Mike Gilbert wrote:
> >>> On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:
> 
>  On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> >   Isn't that duplicating the information of metadata/layout.conf's
> >   'master' key-value pair [1]?
> >
> >
> > Yes, I agree that it would be duplicating that information. As a matter
> > of fact, Michał Górny pointed the same thing out.
> > However, Michał also added, quote: "What's really lacking here is
> > support for specifying dependencies via |repositories.xml|
> 
>  Do we need to duplicate the information in repositories.xml, with all
>  the drawbacks of duplication?
> 
>  Can't eselect repository add the new repository, then read the 'masters'
>  value from layout.conf, and add the missing repositories recursively?
> >>>
> >>> That would be a significant change in behavior for eselect repository.
> >>
> >> Right, but it seems to be a desirable behaviour. Cases where the user
> >> wants to add a repo but not immediately sync it are probably rare.
> >>
> >> Furthermore, it would avoid duplicating the information, which avoids
> >> the typical drawbacks of duplication (e.g., the two sets getting out of
> >> sync).
> >>
> >> I've looked at the eselect-repository code, and it seems not hard to
> >> change the behaviour of "eselect repository add" to add and sync a
> >> repository and then, recursively, add and sync further required
> >> repositories.
> >>
> >> I may give it a shot, but ideally I'd know if it has a chance to be
> >> accepted upstream first. Or maybe there is a good reason why
> >> eselect-repository behaves as it currently does that I am missing?
> >
> > I can't speak for "upstream", but here are my concerns:
> >
> > 1. As a developer, I might just want to create the repos.conf config
> > snippet and sync the repo manually.
> > 2. As a user, I might have any arbitrary reason for not wanting to
> > sync immediately.
>
> Would an opt-out switch be enough to alleviate those concerns of you?

Yes.

>
> > 3. eselect-repository does not currently depend on any particular
> > package manager. It writes config files intended for Portage, but it
> > does not actually invoke any Portage commands. That feels like a
> > significant distinction to me.
> > 4. If you start invoking Portage commands, you then have to deal with
> > the possibility of people using alternate package managers. pkgcore
> > can also utilize Portage's repos.conf, and the user might prefer to
> > use pmaint instead of emaint or emerge --sync.
>
> Those two points seem to be based on the same fundamental concern.
>
> The only portage specific code would be the call to "emaint sync -r
> $repo" (remember that "emerge --sync" is just a wrapper for "emaint sync
> --auto"). I think it would be easy to add later 1. add support for
> different package managers (if the need arises), and 2. make the "sync
> command" user configurable.

Sure, that seems sensible.

Re: [gentoo-dev] Eselect repository feature request

[Florian Schmaus]

On 21/06/2023 17.56, Mike Gilbert wrote:

On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus  wrote:


On 20.06.23 19:26, Mike Gilbert wrote:

On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:


On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:

  Isn't that duplicating the information of metadata/layout.conf's
  'master' key-value pair [1]?


Yes, I agree that it would be duplicating that information. As a matter
of fact, Michał Górny pointed the same thing out.
However, Michał also added, quote: "What's really lacking here is
support for specifying dependencies via |repositories.xml|


Do we need to duplicate the information in repositories.xml, with all
the drawbacks of duplication?

Can't eselect repository add the new repository, then read the 'masters'
value from layout.conf, and add the missing repositories recursively?


That would be a significant change in behavior for eselect repository.


Right, but it seems to be a desirable behaviour. Cases where the user
wants to add a repo but not immediately sync it are probably rare.

Furthermore, it would avoid duplicating the information, which avoids
the typical drawbacks of duplication (e.g., the two sets getting out of
sync).

I've looked at the eselect-repository code, and it seems not hard to
change the behaviour of "eselect repository add" to add and sync a
repository and then, recursively, add and sync further required
repositories.

I may give it a shot, but ideally I'd know if it has a chance to be
accepted upstream first. Or maybe there is a good reason why
eselect-repository behaves as it currently does that I am missing?


I can't speak for "upstream", but here are my concerns:

1. As a developer, I might just want to create the repos.conf config
snippet and sync the repo manually.
2. As a user, I might have any arbitrary reason for not wanting to
sync immediately.


Would an opt-out switch be enough to alleviate those concerns of you?



3. eselect-repository does not currently depend on any particular
package manager. It writes config files intended for Portage, but it
does not actually invoke any Portage commands. That feels like a
significant distinction to me.
4. If you start invoking Portage commands, you then have to deal with
the possibility of people using alternate package managers. pkgcore
can also utilize Portage's repos.conf, and the user might prefer to
use pmaint instead of emaint or emerge --sync.


Those two points seem to be based on the same fundamental concern.

The only portage specific code would be the call to "emaint sync -r 
$repo" (remember that "emerge --sync" is just a wrapper for "emaint sync 
--auto"). I think it would be easy to add later 1. add support for 
different package managers (if the need arises), and 2. make the "sync 
command" user configurable.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> 1. As a developer, I might just want to create the repos.conf config
> snippet and sync the repo manually.
> 2. As a user, I might have any arbitrary reason for not wanting to
> sync immediately.

As a matter of fact, Michał Górny raised the same questions:
"A bit of a problem is how to design UI in eselect-repository. I'm not 100%
sure
that having it automatically install dependent repositories without
confirmation is a good idea"
(
https://github.com/projg2/eselect-repository/issues/20#issuecomment-1579288719)

Ideally, confirmation would be asked before proceeding to sync the other
overlays.
I agree that doing something without the user's knowledge is not ideal.

3. eselect-repository does not currently depend on any particular
> package manager. It writes config files intended for Portage, but it
> does not actually invoke any Portage commands. That feels like a
> significant distinction to me.
> 4. If you start invoking Portage commands, you then have to deal with
> the possibility of people using alternate package managers. pkgcore
> can also utilize Portage's repos.conf, and the user might prefer to
> use pmaint instead of emaint or emerge --sync.


I had not considered that possibility either. In that case, could not the
overlay
dependency resolution be handled as a module?
Said module could be a common interface for different package managers.
Then, the execution of said module would be handled on a per package
manager/sync program basis?

Best regards,
- Tomas Fabrizio Orsi

El mié, 21 jun 2023 a las 12:57, Mike Gilbert ()
escribió:

> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus  wrote:
> >
> > On 20.06.23 19:26, Mike Gilbert wrote:
> > > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus 
> wrote:
> > >>
> > >> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> > >>>  Isn't that duplicating the information of metadata/layout.conf's
> > >>>  'master' key-value pair [1]?
> > >>>
> > >>>
> > >>> Yes, I agree that it would be duplicating that information. As a
> matter
> > >>> of fact, Michał Górny pointed the same thing out.
> > >>> However, Michał also added, quote: "What's really lacking here is
> > >>> support for specifying dependencies via |repositories.xml|
> > >>
> > >> Do we need to duplicate the information in repositories.xml, with all
> > >> the drawbacks of duplication?
> > >>
> > >> Can't eselect repository add the new repository, then read the
> 'masters'
> > >> value from layout.conf, and add the missing repositories recursively?
> > >
> > > That would be a significant change in behavior for eselect repository.
> >
> > Right, but it seems to be a desirable behaviour. Cases where the user
> > wants to add a repo but not immediately sync it are probably rare.
> >
> > Furthermore, it would avoid duplicating the information, which avoids
> > the typical drawbacks of duplication (e.g., the two sets getting out of
> > sync).
> >
> > I've looked at the eselect-repository code, and it seems not hard to
> > change the behaviour of "eselect repository add" to add and sync a
> > repository and then, recursively, add and sync further required
> > repositories.
> >
> > I may give it a shot, but ideally I'd know if it has a chance to be
> > accepted upstream first. Or maybe there is a good reason why
> > eselect-repository behaves as it currently does that I am missing?
>
> I can't speak for "upstream", but here are my concerns:
>
> 1. As a developer, I might just want to create the repos.conf config
> snippet and sync the repo manually.
> 2. As a user, I might have any arbitrary reason for not wanting to
> sync immediately.
> 3. eselect-repository does not currently depend on any particular
> package manager. It writes config files intended for Portage, but it
> does not actually invoke any Portage commands. That feels like a
> significant distinction to me.
> 4. If you start invoking Portage commands, you then have to deal with
> the possibility of people using alternate package managers. pkgcore
> can also utilize Portage's repos.conf, and the user might prefer to
> use pmaint instead of emaint or emerge --sync.
>
>

Re: [gentoo-dev] Eselect repository feature request

[Mike Gilbert]

On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus  wrote:
>
> On 20.06.23 19:26, Mike Gilbert wrote:
> > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:
> >>
> >> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> >>>  Isn't that duplicating the information of metadata/layout.conf's
> >>>  'master' key-value pair [1]?
> >>>
> >>>
> >>> Yes, I agree that it would be duplicating that information. As a matter
> >>> of fact, Michał Górny pointed the same thing out.
> >>> However, Michał also added, quote: "What's really lacking here is
> >>> support for specifying dependencies via |repositories.xml|
> >>
> >> Do we need to duplicate the information in repositories.xml, with all
> >> the drawbacks of duplication?
> >>
> >> Can't eselect repository add the new repository, then read the 'masters'
> >> value from layout.conf, and add the missing repositories recursively?
> >
> > That would be a significant change in behavior for eselect repository.
>
> Right, but it seems to be a desirable behaviour. Cases where the user
> wants to add a repo but not immediately sync it are probably rare.
>
> Furthermore, it would avoid duplicating the information, which avoids
> the typical drawbacks of duplication (e.g., the two sets getting out of
> sync).
>
> I've looked at the eselect-repository code, and it seems not hard to
> change the behaviour of "eselect repository add" to add and sync a
> repository and then, recursively, add and sync further required
> repositories.
>
> I may give it a shot, but ideally I'd know if it has a chance to be
> accepted upstream first. Or maybe there is a good reason why
> eselect-repository behaves as it currently does that I am missing?

I can't speak for "upstream", but here are my concerns:

1. As a developer, I might just want to create the repos.conf config
snippet and sync the repo manually.
2. As a user, I might have any arbitrary reason for not wanting to
sync immediately.
3. eselect-repository does not currently depend on any particular
package manager. It writes config files intended for Portage, but it
does not actually invoke any Portage commands. That feels like a
significant distinction to me.
4. If you start invoking Portage commands, you then have to deal with
the possibility of people using alternate package managers. pkgcore
can also utilize Portage's repos.conf, and the user might prefer to
use pmaint instead of emaint or emerge --sync.

Re: [gentoo-dev] Eselect repository feature request

[Florian Schmaus]

On 20.06.23 19:26, Mike Gilbert wrote:

On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:


On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:

 Isn't that duplicating the information of metadata/layout.conf's
 'master' key-value pair [1]?


Yes, I agree that it would be duplicating that information. As a matter
of fact, Michał Górny pointed the same thing out.
However, Michał also added, quote: "What's really lacking here is
support for specifying dependencies via |repositories.xml|


Do we need to duplicate the information in repositories.xml, with all
the drawbacks of duplication?

Can't eselect repository add the new repository, then read the 'masters'
value from layout.conf, and add the missing repositories recursively?


That would be a significant change in behavior for eselect repository.


Right, but it seems to be a desirable behaviour. Cases where the user 
wants to add a repo but not immediately sync it are probably rare.


Furthermore, it would avoid duplicating the information, which avoids 
the typical drawbacks of duplication (e.g., the two sets getting out of 
sync).


I've looked at the eselect-repository code, and it seems not hard to 
change the behaviour of "eselect repository add" to add and sync a 
repository and then, recursively, add and sync further required 
repositories.


I may give it a shot, but ideally I'd know if it has a chance to be 
accepted upstream first. Or maybe there is a good reason why 
eselect-repository behaves as it currently does that I am missing?


- Flow

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> $ sudo emerge --sync
> Unavailable repository 'foo' referenced by masters entry in
> '/var/db/repos/gentoo/metadata/layout.conf'

Oh! I was not aware of this feature. I apologize.
So, in theory, could '%s' be used to automatically enable the missing
repository
(if available in repositories.xml)?

Thank you for you insight,

Best regards,
- Tomas Fabrizio Orsi

El mié, 21 jun 2023 a las 12:07, Mike Gilbert ()
escribió:

> On Wed, Jun 21, 2023 at 10:43 AM TOMAS FABRIZIO ORSI 
> wrote:
> >>
> >> Sure, I think it could work.
> >
> > Great to hear.
> > In that case I could try to give it a try and make a pull request to the
> emerge --sync with a basic idea.
> > Any tips?
>
> So emerge already emits a warning message when a repo is missing:
>
>
> https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/repository/config.py?h=portage-3.0.48.1#n1070
>
> That looks something like this:
>
> $ sudo emerge --sync
> Unavailable repository 'foo' referenced by masters entry in
> '/var/db/repos/gentoo/metadata/layout.conf'
>
>

Re: [gentoo-dev] Eselect repository feature request

[Mike Gilbert]

On Wed, Jun 21, 2023 at 10:43 AM TOMAS FABRIZIO ORSI  wrote:
>>
>> Sure, I think it could work.
>
> Great to hear.
> In that case I could try to give it a try and make a pull request to the 
> emerge --sync with a basic idea.
> Any tips?

So emerge already emits a warning message when a repo is missing:

https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/repository/config.py?h=portage-3.0.48.1#n1070

That looks something like this:

$ sudo emerge --sync
Unavailable repository 'foo' referenced by masters entry in
'/var/db/repos/gentoo/metadata/layout.conf'

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> Sure, I think it could work.

Great to hear.
In that case I could try to give it a try and make a pull request to the
emerge --sync with a basic idea.
Any tips?
If anyone else is interested/free (I'm guessing the latter is unlikely
haha.) I'd love to have a helping hand!

Thank you for your kind responses,

Best regards,
- Tomas Fabrizio Orsi


El mié, 21 jun 2023 a las 11:30, Andrew Ammerlaan (<
andrewammerl...@gentoo.org>) escribió:

> On 21/06/2023 16:12, TOMAS FABRIZIO ORSI wrote:
> > In any case, this is just something to keep in mind when writing this
> > check. It is not fully guaranteed that eselect repository can find
> the
> > repository that is requested in some master= entry.
> >
> > Great point.
> > Btw, in your opinion, do you think having this emerge --sync + eselect
> > repository feature is doable?
>
> Sure, I think it could work.
>
> Best regards,
> Andrew
>
>
>

Re: [gentoo-dev] Eselect repository feature request

[Andrew Ammerlaan]

On 21/06/2023 16:12, TOMAS FABRIZIO ORSI wrote:

In any case, this is just something to keep in mind when writing this
check. It is not fully guaranteed that eselect repository can find the
repository that is requested in some master= entry.

Great point.
Btw, in your opinion, do you think having this emerge --sync + eselect 
repository feature is doable?


Sure, I think it could work.

Best regards,
Andrew

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> I just checked the internal overlays team guide[1] and it does
> explicitly say that repo_name should match the repositories.xml .

Oh, great news then. Thanks for checking. Also thank you overlays team!

That being said it is possible for the
> owner to change repo_name and (accidentally) not update
> repositories.xml. These cases should be fixed but exactly how would have
> to be determined on a case by case basis.
>
That is true, however I think those are "edge" cases. Furthermore, how
often do
people change their overlay's name? I legitimately do not know.

In any case, this is just something to keep in mind when writing this
> check. It is not fully guaranteed that eselect repository can find the
> repository that is requested in some master= entry.
>
Great point.
Btw, in your opinion, do you think having this emerge --sync + eselect
repository feature is doable?

Best regards,
- Tomas Fabrizio Orsi


El mié, 21 jun 2023 a las 10:58, Andrew Ammerlaan (<
andrewammerl...@gentoo.org>) escribió:

> On 21/06/2023 15:40, TOMAS FABRIZIO ORSI wrote:
> > What I meant is that emerge --sync/eix --sync does this check
> > instead of
> > eselect repository. To me this makes sense since we can only do this
> > check *after* syncing.
> >
> > That is a great point; I had not considered it.
> > So, you are saying to have emerge --sync/eix --sync check the masters
> > key and then warn the user of not synced up overlays, correct?
>
> Yes
>
> > This however would require
> > that profiles/repo_name is always equal to the name entry in
> > repositories.xml, I'm not sure if this is currently always the case.
> >
> > I had not considered this possibility either.
> > If that's the case, then I believe there are to possible behaviors:
> > If the names do match, then emerge --sync/eix --sync could both:
> >   1. issue a warning of the missing overlay dependency
> >   2. run the command to add said overlay (with confirmation).
> > On the other hand, if the names do not match, a missing dependency
> warning
> > could be issued, skipping the second step.
> > This sounds to me to be fairly reasonable behaviour.
> >
> > In the cases where the names do not match; what could be the best
> > solution to "fix" this? Change repositories.xml on a case by case basis?
> > Ask overlay owners to change their profiles/repo_name and
> > profiles/masters key? Neither?
>
> I just checked the internal overlays team guide[1] and it does
> explicitly say that repo_name should match the repositories.xml .
> So probably there is no problem. That being said it is possible for the
> owner to change repo_name and (accidentally) not update
> repositories.xml. These cases should be fixed but exactly how would have
> to be determined on a case by case basis.
>
> In any case, this is just something to keep in mind when writing this
> check. It is not fully guaranteed that eselect repository can find the
> repository that is requested in some master= entry.
>
> Best regards,
> Andrew
>
> [1]
> https://wiki.gentoo.org/wiki/Project:Overlays/Internal_Overlays_team_guide
>
>
>

Re: [gentoo-dev] Eselect repository feature request

[Andrew Ammerlaan]

On 21/06/2023 15:40, TOMAS FABRIZIO ORSI wrote:

What I meant is that emerge --sync/eix --sync does this check
instead of
eselect repository. To me this makes sense since we can only do this
check *after* syncing. 


That is a great point; I had not considered it.
So, you are saying to have emerge --sync/eix --sync check the masters
key and then warn the user of not synced up overlays, correct?


Yes


This however would require
that profiles/repo_name is always equal to the name entry in
repositories.xml, I'm not sure if this is currently always the case.

I had not considered this possibility either.
If that's the case, then I believe there are to possible behaviors:
If the names do match, then emerge --sync/eix --sync could both:
  1. issue a warning of the missing overlay dependency
  2. run the command to add said overlay (with confirmation).
On the other hand, if the names do not match, a missing dependency warning
could be issued, skipping the second step.
This sounds to me to be fairly reasonable behaviour.

In the cases where the names do not match; what could be the best
solution to "fix" this? Change repositories.xml on a case by case basis?
Ask overlay owners to change their profiles/repo_name and
profiles/masters key? Neither?


I just checked the internal overlays team guide[1] and it does 
explicitly say that repo_name should match the repositories.xml . 
So probably there is no problem. That being said it is possible for the 
owner to change repo_name and (accidentally) not update 
repositories.xml. These cases should be fixed but exactly how would have 
to be determined on a case by case basis.


In any case, this is just something to keep in mind when writing this 
check. It is not fully guaranteed that eselect repository can find the 
repository that is requested in some master= entry.


Best regards,
Andrew

[1] 
https://wiki.gentoo.org/wiki/Project:Overlays/Internal_Overlays_team_guide

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> What I meant is that emerge --sync/eix --sync does this check instead of
> eselect repository. To me this makes sense since we can only do this
> check *after* syncing.

That is a great point; I had not considered it.
So, you are saying to have emerge --sync/eix --sync check the masters
key and then warn the user of not synced up overlays, correct?

This however would require
> that profiles/repo_name is always equal to the name entry in
> repositories.xml, I'm not sure if this is currently always the case.

I had not considered this possibility either.
If that's the case, then I believe there are to possible behaviors:
If the names do match, then emerge --sync/eix --sync could both:
 1. issue a warning of the missing overlay dependency
 2. run the command to add said overlay (with confirmation).
On the other hand, if the names do not match, a missing dependency warning
could be issued, skipping the second step.
This sounds to me to be fairly reasonable behaviour.

In the cases where the names do not match; what could be the best
solution to "fix" this? Change repositories.xml on a case by case basis?
Ask overlay owners to change their profiles/repo_name and
profiles/masters key? Neither?

Best regards,
- Tomas Fabrizio Orsi

El mié, 21 jun 2023 a las 4:15, Andrew Ammerlaan (<
andrewammerl...@gentoo.org>) escribió:

> On 21/06/2023 04:17, TOMAS FABRIZIO ORSI wrote:
> > A warning could be a great way of making the user aware of this
> situation.
> > Having said that, if eselect repository is able to check and warn the
> > user of a not synced overlay(ies) dependency, then the hard bit is done
>
> What I meant is that emerge --sync/eix --sync does this check instead of
> eselect repository. To me this makes sense since we can only do this
> check *after* syncing. Plus the user can also make changes to repos.conf
> without using eselect repository, having the check done post-syncing
> covers these cases as well.
>
> You're probably right that once we have some message that says "Warning:
> {repo1} is missing, it is required by {repo2}" it should be trivial to
> call 'eselect repository enable {repo1}'. This however would require
> that profiles/repo_name is always equal to the name entry in
> repositories.xml, I'm not sure if this is currently always the case.
>
> Best regards,
> Andrew
>
>
>

Re: [gentoo-dev] Eselect repository feature request

[Andrew Ammerlaan]

On 21/06/2023 04:17, TOMAS FABRIZIO ORSI wrote:

A warning could be a great way of making the user aware of this situation.
Having said that, if eselect repository is able to check and warn the 
user of a not synced overlay(ies) dependency, then the hard bit is done 


What I meant is that emerge --sync/eix --sync does this check instead of 
eselect repository. To me this makes sense since we can only do this 
check *after* syncing. Plus the user can also make changes to repos.conf 
without using eselect repository, having the check done post-syncing 
covers these cases as well.


You're probably right that once we have some message that says "Warning: 
{repo1} is missing, it is required by {repo2}" it should be trivial to 
call 'eselect repository enable {repo1}'. This however would require 
that profiles/repo_name is always equal to the name entry in 
repositories.xml, I'm not sure if this is currently always the case.


Best regards,
Andrew

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

A warning could be a great way of making the user aware of this situation.
Having said that, if eselect repository is able to check and warn the user
of a not synced overlay(ies) dependency, then the hard bit is done (Right?).
Being able to "sync it for them" should only be a tiny extra step. That
step being: "Hey, there's a dependency that you are missing. Would you like
to add it? (Yes/No)"

Best regards,
- Tomas Fabrizio Orsi


El mar, 20 jun 2023 a las 15:07, Andrew Ammerlaan (<
andrewammerl...@gentoo.org>) escribió:

> On 20/06/2023 19:26, Mike Gilbert wrote:
> > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:
> >>
> >> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> >>>  Isn't that duplicating the information of metadata/layout.conf's
> >>>  'master' key-value pair [1]?
> >>>
> >>>
> >>> Yes, I agree that it would be duplicating that information. As a matter
> >>> of fact, Michał Górny pointed the same thing out.
> >>> However, Michał also added, quote: "What's really lacking here is
> >>> support for specifying dependencies via |repositories.xml|
> >>
> >> Do we need to duplicate the information in repositories.xml, with all
> >> the drawbacks of duplication?
> >>
> >> Can't eselect repository add the new repository, then read the 'masters'
> >> value from layout.conf, and add the missing repositories recursively?
> >
> > That would be a significant change in behavior for eselect repository.
> > Currently, it does not actually sync any repos; it just manages the
> > config in /etc/portage/repos.conf.
> >
> Or maybe we just output a warning after syncing if a repository listed
> in masters= is not enabled? Less automated, but simpler. I don't think
> this situation happens very often so this is probably good enough IMO.
>
> Best regards,
> Andrew
>
>

Re: [gentoo-dev] Eselect repository feature request

[Andrew Ammerlaan]

On 20/06/2023 19:26, Mike Gilbert wrote:

On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:


On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:

 Isn't that duplicating the information of metadata/layout.conf's
 'master' key-value pair [1]?


Yes, I agree that it would be duplicating that information. As a matter
of fact, Michał Górny pointed the same thing out.
However, Michał also added, quote: "What's really lacking here is
support for specifying dependencies via |repositories.xml|


Do we need to duplicate the information in repositories.xml, with all
the drawbacks of duplication?

Can't eselect repository add the new repository, then read the 'masters'
value from layout.conf, and add the missing repositories recursively?


That would be a significant change in behavior for eselect repository.
Currently, it does not actually sync any repos; it just manages the
config in /etc/portage/repos.conf.

Or maybe we just output a warning after syncing if a repository listed 
in masters= is not enabled? Less automated, but simpler. I don't think 
this situation happens very often so this is probably good enough IMO.


Best regards,
Andrew

Re: [gentoo-dev] Eselect repository feature request

[Mike Gilbert]

On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus  wrote:
>
> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> > Isn't that duplicating the information of metadata/layout.conf's
> > 'master' key-value pair [1]?
> >
> >
> > Yes, I agree that it would be duplicating that information. As a matter
> > of fact, Michał Górny pointed the same thing out.
> > However, Michał also added, quote: "What's really lacking here is
> > support for specifying dependencies via |repositories.xml|
>
> Do we need to duplicate the information in repositories.xml, with all
> the drawbacks of duplication?
>
> Can't eselect repository add the new repository, then read the 'masters'
> value from layout.conf, and add the missing repositories recursively?

That would be a significant change in behavior for eselect repository.
Currently, it does not actually sync any repos; it just manages the
config in /etc/portage/repos.conf.

Re: [gentoo-dev] Eselect repository feature request

[Florian Schmaus]

On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:

Isn't that duplicating the information of metadata/layout.conf's
'master' key-value pair [1]?


Yes, I agree that it would be duplicating that information. As a matter 
of fact, Michał Górny pointed the same thing out.
However, Michał also added, quote: "What's really lacking here is 
support for specifying dependencies via |repositories.xml|


Do we need to duplicate the information in repositories.xml, with all 
the drawbacks of duplication?


Can't eselect repository add the new repository, then read the 'masters' 
value from layout.conf, and add the missing repositories recursively?


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Eselect repository feature request

[TOMAS FABRIZIO ORSI]

>
> Isn't that duplicating the information of metadata/layout.conf's
> 'master' key-value pair [1]?
>

Yes, I agree that it would be duplicating that information. As a matter of
fact, Michał Górny pointed the same thing out.
However, Michał also added, quote: "What's really lacking here is support
for specifying dependencies via repositories.xml. Once such a thing is
implemented, We can look into having eselect-repository handle that once
it's specified." (Here's the link to the conversation:
https://github.com/projg2/eselect-repository/issues/20#issuecomment-1579098528
)
That's why I added the  line in the repositories.xml template.

Having said that, maybe the information present in the masters key could be
used to add the overlay dependencies in the repositories present in the xml
file as of today.

Thank you for your reply,

--
Best regards,
- Tomas Fabrizio Orsi


El mar, 20 jun 2023 a las 10:44, Florian Schmaus ()
escribió:

> On 18.06.23 22:39, TOMAS FABRIZIO ORSI wrote:
> > Hello gentoo devs. The other day I made a feature suggestion to the
> > eselect repository github page. (Here's the link:
> > https://github.com/projg2/eselect-repository/issues/20
> > ).
> > Michał Górny suggested that I should contact the gentoo-dev mailing list
> > with my suggestion, so here it is: My suggestion is to make it possible
> > for eselect repository to manage overlay dependencies.
> >
> > As it stands, and as far as I'm concerned, there is no "proper" way of
> > having an ebuild dependency from another overlay. So overlay writers
> > have to copy ebuilds from other overlays or rewrite them. This implies
> > synchronization issues (where the "copied" ebuilds get out of sync from
> > the original ebuild) and time loss (people writing the same ebuild more
> > than once).
> >
> > Michał Górny suggested that I should make an edit to the
> > repositories.xml file in order to tackle the issue.
> >
> > This is my general idea:
> > (I am using the github template as an example, but the idea should apply
> > to all other templates. I got this file from
> >
> https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/repositories.xml
> <
> https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/repositories.xml
> >).
> >
> >* GITHUB TEMPLATE
> >  
> >X
> >XX
> >https://github.com//
> > 
> >
> >  X
> >  X
> >
> >https://github.com//.git
> > 
> >git+ssh://g...@github.com//.git
> > 
> >https://github.com///commits/master.atom
> > 
> >
> >overlayName
> >
> >  
>
> Isn't that duplicating the information of metadata/layout.conf's
> 'master' key-value pair [1]?
>
> - Flow
>
> 1:
> https://wiki.gentoo.org/wiki/Repository_format/metadata/layout.conf#masters
>

Re: [gentoo-dev] Eselect repository feature request

[Florian Schmaus]

On 18.06.23 22:39, TOMAS FABRIZIO ORSI wrote:
Hello gentoo devs. The other day I made a feature suggestion to the 
eselect repository github page. (Here's the link: 
https://github.com/projg2/eselect-repository/issues/20 
).
Michał Górny suggested that I should contact the gentoo-dev mailing list 
with my suggestion, so here it is: My suggestion is to make it possible 
for eselect repository to manage overlay dependencies.


As it stands, and as far as I'm concerned, there is no "proper" way of 
having an ebuild dependency from another overlay. So overlay writers 
have to copy ebuilds from other overlays or rewrite them. This implies 
synchronization issues (where the "copied" ebuilds get out of sync from 
the original ebuild) and time loss (people writing the same ebuild more 
than once).


Michał Górny suggested that I should make an edit to the 
repositories.xml file in order to tackle the issue.


This is my general idea:
(I am using the github template as an example, but the idea should apply 
to all other templates. I got this file from 
https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/repositories.xml ).


   * GITHUB TEMPLATE
     
       X
       XX
       https://github.com// 


       
         X
         X
       
       https://github.com//.git 

       git+ssh://g...@github.com//.git 

       https://github.com///commits/master.atom 


       
           overlayName
       
     


Isn't that duplicating the information of metadata/layout.conf's 
'master' key-value pair [1]?


- Flow

1: 
https://wiki.gentoo.org/wiki/Repository_format/metadata/layout.conf#masters


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] eselect init

[Jason A. Donenfeld]

If we're to support sysvinit and systemd at the same time, let each use
their upstream paths. This means sysvinit gets /sbin/init.

This also means that business can continue as usual, and nobody is forced
to install eselect-init. The current system works for users who don't care
or aren't aware of this innovation. Motivated users who want the ability to
change back and forth can emerge eselect-init and modify their init= line
in the bootloader.

This is cleaner because it keeps things more in lockstep with upstream.

This is also politically easier, as it doesn't require any notable changes
or new ebulds to openrc folks, which I can imagine might be met with
opposition here and there.

Re: [gentoo-dev] eselect init

[hasufell]

On 06/22/2013 01:23 PM, Jason A. Donenfeld wrote:
 and nobody is forced to install eselect-init

That was already demanded earlier in this discussion, but I don't see
any response from the initiators of this idea (possible I just missed it).

Anyway... if they do such a global change without discussing this
particular problem, then it will cause someone to revert it or ask for
QA/council intervention.

Re: [gentoo-dev] eselect init

[Michał Górny]

Dnia 2013-06-20, o godz. 23:16:00
William Hubbs willi...@gentoo.org napisał(a):

 On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote:
  Dnia 2013-06-20, o godz. 15:56:09
  William Hubbs willi...@gentoo.org napisał(a):
  
   On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
There is a new version of eselect-init in the systemd-love overlay to 
play with.
The new version saw the following major changes:

- the /sbin/init (aka the symlink that eselect-init handles) can be
changed to whatever one wants through make.conf [1] (this is a compile
time option, as documented in the eclass)
   
   Why do we need to mess with /sbin/init at all?
  
  Yes, we do because we don't want sysvinit randomly getting run
  as fallback and messing with our systems.
 
 I don't understand what you are saying here.
 
 If eselect-init installs the wrapper as /sbin/einit, we don't have to
 touch /sbin/init at all, then, the only thing someone would have to do
 is to add an entry to their boot loader with init=/sbin/einit on the kcl
 to use it.

But *if* the wrapper fails to run somehow, e.g. becomes broken,
the kernel will fallback to the standard location.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Michael Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/21/2013 04:39 AM, Michał Górny wrote:
 Dnia 2013-06-20, o godz. 15:56:09 William Hubbs
 willi...@gentoo.org napisał(a):
 
 On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
 There is a new version of eselect-init in the systemd-love
 overlay to play with. The new version saw the following major
 changes:
 
 - the /sbin/init (aka the symlink that eselect-init handles)
 can be changed to whatever one wants through make.conf [1]
 (this is a compile time option, as documented in the eclass)
 
 Why do we need to mess with /sbin/init at all?
 
 Yes, we do because we don't want sysvinit randomly getting run as
 fallback and messing with our systems.
So what's the point in having it optional, if sysvinit would just mess
around with it.

You'd only hit this, if you start your userland with an foreign kernel.
Forgotten bootloader arguments can be defaulted with ...

 I like the suggestion that came up here on the list a while back,
 have the eselect init module install its own symlink at, say,
 /sbin/einit. You would still have to have the user edit their
 boot loader configuration file one time if they want to use this,
 but this makes it completely opt-in.
 
 Plus hacking kernel sources to disable /sbin/init fallback.

CONFIG_CMDLINE=/sbin/whatever works, i use it for root=, crypt_dev, ...
CONFIG_CMDLINE_OVERRIDE should stay off to respect bootloader cmdline.

[ working with foreign init systems (runit-musl based ignite on
archlinux, NoUpgrade=sbin/init aka CONFIG_PROTECT does work, too.]

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHEKzMACgkQknrdDGLu8JA6AwD+MyTTKeHlNN/1Nud/G0L7XnA+
hdJl4qATOU3MkyqDQw0A+wao6tYrHTFWCt4MmTOxl3gsBvUvE/w4sQyZcPTElg3h
=XwPu
-END PGP SIGNATURE-

Re: [gentoo-dev] eselect init

[Fabio Erculiani]

For me, the big selling points of eselect-init are:

1. as release engineer, i can prepare images that use either systemd
or openrc (at present time these are the two supported options) and do
it reliably, programmatically.
2. as distro maintainer, i can roll out a migration path from openrc
to systemd (or vice versa). The properties of this migration path I am
looking for are reliability and atomicity. Basically, once you move
logind/consolekit detection to runtime (and believe it or not, many
upstream just get it wrong), and have feature parity in the systemd
units available (wrt openrc initscripts), switching over is a matter
of 2 (soon 1) commands.

Both of them are quite important, because there are scenarios in where
systemd fits better than openrc, and scenarios in where openrc is a
better fit (older kernels, production system with custom init scripts
that are not worth the porting, etc).
Making the switch between openrc and systemd easy is a big win (for
both developers, distro maintainers, users) and makes Gentoo more
attractive, but this is another topic...

-- 
Fabio Erculiani

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El vie, 21-06-2013 a las 13:19 +0200, Fabio Erculiani escribió:
 For me, the big selling points of eselect-init are:
 
 1. as release engineer, i can prepare images that use either systemd
 or openrc (at present time these are the two supported options) and do
 it reliably, programmatically.
 2. as distro maintainer, i can roll out a migration path from openrc
 to systemd (or vice versa). The properties of this migration path I am
 looking for are reliability and atomicity. Basically, once you move
 logind/consolekit detection to runtime (and believe it or not, many
 upstream just get it wrong), and have feature parity in the systemd
 units available (wrt openrc initscripts), switching over is a matter
 of 2 (soon 1) commands.
 
 Both of them are quite important, because there are scenarios in where
 systemd fits better than openrc, and scenarios in where openrc is a
 better fit (older kernels, production system with custom init scripts
 that are not worth the porting, etc).
 Making the switch between openrc and systemd easy is a big win (for
 both developers, distro maintainers, users) and makes Gentoo more
 attractive, but this is another topic...
 

Thanks for the explanation. But I think that, currently, the only
remaining objection is whether play with /sbin/init (that needs
sysvinit to be changed if I don't misremember) or with /sbin/einit.
Looks like mgorny has shown some problems on relying on einit instead
of plain init regarding to fallback :/

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 01:26 PM, Pacho Ramos wrote:
 Thanks for the explanation. But I think that, currently, the only
 remaining objection is whether play with /sbin/init (that needs
 sysvinit to be changed if I don't misremember) or with /sbin/einit.
 Looks like mgorny has shown some problems on relying on einit instead
 of plain init regarding to fallback :/

I prefer having /sbin/init used for the pivot since /sbin/einit is a bit
more brittle and as Fabio did the whole machinery is _still_ opt-in.

lu

Re: [gentoo-dev] eselect init

[William Hubbs]

On Fri, Jun 21, 2013 at 01:50:02PM +0200, Luca Barbato wrote:
 On 06/21/2013 01:26 PM, Pacho Ramos wrote:
  Thanks for the explanation. But I think that, currently, the only
  remaining objection is whether play with /sbin/init (that needs
  sysvinit to be changed if I don't misremember) or with /sbin/einit.
  Looks like mgorny has shown some problems on relying on einit instead
  of plain init regarding to fallback :/
 
 I prefer having /sbin/init used for the pivot since /sbin/einit is a bit
 more brittle and as Fabio did the whole machinery is _still_ opt-in.

No, he has his own versions of the systemd and sysvinit ebuilds which
move some of the installation to non-standard places as part of this
machinery, so it is not opt-in.

Also, there was an email on this thread showing that using
init=/sbin/einit works, so I'm not seeing what mgorny's objections are.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[William Hubbs]

On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
  If eselect-init installs the wrapper as /sbin/einit, we don't have to
  touch /sbin/init at all, then, the only thing someone would have to do
  is to add an entry to their boot loader with init=/sbin/einit on the kcl
  to use it.
 
 But *if* the wrapper fails to run somehow, e.g. becomes broken,
 the kernel will fallback to the standard location.

Yes, but if the wrapper replaces /sbin/init, like it does now, and the
wrapper gets broken, I think you are left with an unbootable system.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[Michał Górny]

Dnia 2013-06-21, o godz. 10:16:10
William Hubbs willi...@gentoo.org napisał(a):

 On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
   If eselect-init installs the wrapper as /sbin/einit, we don't have to
   touch /sbin/init at all, then, the only thing someone would have to do
   is to add an entry to their boot loader with init=/sbin/einit on the kcl
   to use it.
  
  But *if* the wrapper fails to run somehow, e.g. becomes broken,
  the kernel will fallback to the standard location.
 
 Yes, but if the wrapper replaces /sbin/init, like it does now, and the
 wrapper gets broken, I think you are left with an unbootable system.

Then kernel falls back to safe /bin/sh which is a minimal safe fallback.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Fabio Erculiani]

Fix the reason why the wrapper got broken then.
If the wrapper broke, it is most likely a symptom of a bigger problem.

I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
(or /bin/sysvinit?), anyway...

-- 
Fabio Erculiani

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió:
[...]
 No, he has his own versions of the systemd and sysvinit ebuilds which
 move some of the installation to non-standard places as part of this
 machinery, so it is not opt-in.
 
 Also, there was an email on this thread showing that using
 init=/sbin/einit works, so I'm not seeing what mgorny's objections are.
 
 William

I think mgorny was referring to a case where einit fails to work and,
then, kernel will fallback to using /sbin/init, that could cause
problems as it would always run /sbin/init from sysvinit... but maybe he
was referring to something else :|

Re: [gentoo-dev] eselect init

[Markos Chandras]

On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-06-21, o godz. 10:16:10
 William Hubbs willi...@gentoo.org napisał(a):

 On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
   If eselect-init installs the wrapper as /sbin/einit, we don't have to
   touch /sbin/init at all, then, the only thing someone would have to do
   is to add an entry to their boot loader with init=/sbin/einit on the kcl
   to use it.
 
  But *if* the wrapper fails to run somehow, e.g. becomes broken,
  the kernel will fallback to the standard location.

 Yes, but if the wrapper replaces /sbin/init, like it does now, and the
 wrapper gets broken, I think you are left with an unbootable system.

 Then kernel falls back to safe /bin/sh which is a minimal safe fallback.

 --
 Best regards,
 Michał Górny

Correct. Even if your init end up being broken you end up with a shell
so you can fix things yourself.

(from init/main.c)

/*
 * We try each of these until one succeeds.
 *
 * The Bourne shell can be used instead of init if we are
 * trying to recover a really broken machine.
 */
if (execute_command) {
if (!run_init_process(execute_command))
return 0;
pr_err(Failed to execute %s.  Attempting defaults...\n,
execute_command);
}
if (!run_init_process(/sbin/init) ||
!run_init_process(/etc/init) ||
!run_init_process(/bin/init) ||
!run_init_process(/bin/sh))
return 0;


But this is not pretty. Not everyone knows how to recover from a
broken init. The eselect module aims to offer an elegant way to
switch init systems but if that fails then you need some advanced
knowledge to fix your system. So my opinion is that before such
thing is introduce to the wild, we need to be confident that it will
never fail but even if it does, you need to provide a documented way
on how to recover. Maybe a bold warning with post-mortem instructions
when you first invoke the eselect module is one way to do it.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] eselect init

[William Hubbs]

On Fri, Jun 21, 2013 at 05:23:51PM +0200, Fabio Erculiani wrote:
 I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
 (or /bin/sysvinit?), anyway...

Feel free to file a request with sysvinit upstream to see if they will
do this; I don't think we should be randomly renaming files at the
distro level.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[William Hubbs]

On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
 On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
  Dnia 2013-06-21, o godz. 10:16:10
  William Hubbs willi...@gentoo.org napisał(a):
 
  On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
If eselect-init installs the wrapper as /sbin/einit, we don't have to
touch /sbin/init at all, then, the only thing someone would have to do
is to add an entry to their boot loader with init=/sbin/einit on the 
kcl
to use it.
  
   But *if* the wrapper fails to run somehow, e.g. becomes broken,
   the kernel will fallback to the standard location.
 
  Yes, but if the wrapper replaces /sbin/init, like it does now, and the
  wrapper gets broken, I think you are left with an unbootable system.
 
  Then kernel falls back to safe /bin/sh which is a minimal safe fallback.
 
  --
  Best regards,
  Michał Górny
 
 Correct. Even if your init end up being broken you end up with a shell
 so you can fix things yourself.

The case we are ignoring here is the indirection in the wrapper. e.g.
the wrapper, /sbin/init is a valid process, but the process it tries to
run, say /bin/foobar, is not.

I'm thinking that no matter where we put the wrapper, either as a custom
version of /sbin/init or as something like /bin/einit, once the kernel
hands things off to the wrapper, if the wrapper fails to run the
executable it is directed to run, we are hosed.

If there is a separate boot loader entry to run the wrapper, users
are able to opt in to using the wrapper, but they can recover if it
fails. That is why I'm against having the wrapper replace the standard
init.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 05:23 PM, Fabio Erculiani wrote:
 Fix the reason why the wrapper got broken then.
 If the wrapper broke, it is most likely a symptom of a bigger problem.
 
 I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
 (or /bin/sysvinit?), anyway...
 

/bin/init

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 06:50 PM, William Hubbs wrote:
 On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
 On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-06-21, o godz. 10:16:10
 William Hubbs willi...@gentoo.org napisał(a):

 On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
 If eselect-init installs the wrapper as /sbin/einit, we don't have to
 touch /sbin/init at all, then, the only thing someone would have to do
 is to add an entry to their boot loader with init=/sbin/einit on the kcl
 to use it.

 But *if* the wrapper fails to run somehow, e.g. becomes broken,
 the kernel will fallback to the standard location.

 Yes, but if the wrapper replaces /sbin/init, like it does now, and the
 wrapper gets broken, I think you are left with an unbootable system.

 Then kernel falls back to safe /bin/sh which is a minimal safe fallback.

 --
 Best regards,
 Michał Górny

 Correct. Even if your init end up being broken you end up with a shell
 so you can fix things yourself.
 
 The case we are ignoring here is the indirection in the wrapper. e.g.
 the wrapper, /sbin/init is a valid process, but the process it tries to
 run, say /bin/foobar, is not.
 
 I'm thinking that no matter where we put the wrapper, either as a custom
 version of /sbin/init or as something like /bin/einit, once the kernel
 hands things off to the wrapper, if the wrapper fails to run the
 executable it is directed to run, we are hosed.
 

I asked to mgorny to try that already, and he did and reported already,
you can try for yourself and see what happens.

lu - no, I won't tell what happens so you will try for yourself

Re: [gentoo-dev] eselect init

[Ulrich Mueller]

 On Fri, 21 Jun 2013, Luca Barbato wrote:

 /bin/init

Why /bin? It shouldn't be in users' PATH.

Ulrich

Re: [gentoo-dev] eselect init

[Michael Weber]

On 06/22/2013 03:27 AM, Ulrich Mueller wrote:
 On Fri, 21 Jun 2013, Luca Barbato wrote:
 
 /bin/init
 
 Why /bin? It shouldn't be in users' PATH.
users' PATH, a joyful blast from the past, if I'm allowed to say that.
But it's all /usr/bin now [1].

Off topic -- I always have sbins in my non-root path to use non-root
features of e.g. /sbin/ip.

[1]
https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org

Re: [gentoo-dev] eselect init

[Fabio Erculiani]

There is a new version of eselect-init in the systemd-love overlay to play with.
The new version saw the following major changes:

- the /sbin/init (aka the symlink that eselect-init handles) can be
changed to whatever one wants through make.conf [1] (this is a compile
time option, as documented in the eclass)
- only init is currently handled by eselect-init, which is now using a
very small wrapper POSIX shell script to redirect the calls to the
currently running init [2]
- the wrapper and its code paths are now documented in the
eselect-init eclass [2] [3]

You need systemd and sysvinit from the same overlay for it to work.
If you intend to use switch between systemd to openrc (and vice
versa), make sure to install the rest of the packages in that overlay.
At the moment, if you want to switch, you also need to use
eselect-settingsd. However, I am planning to drop eselect-settingsd:
openrc-settingsd and systemd share the same settingsd dbus interface
while they call different executables, systemd initializes its dbus
services without relying on dbus activation, so the Exec= part of the
service descriptor file is currently set to /bin/false, this rings a
bell :D, because it is possible to replace /bin/false with a script
that starts the respective services when dbus activation is used
(which means that systemd hasn't booted the system). This would make
possible to remove the blocker dependency in openrc-settingsd and
systemd somehow.

[1] 
https://github.com/Sabayon/systemd-love/commit/ced29311348a81a2573b030b1316f1c3a0335c5b
[2] 
https://github.com/Sabayon/systemd-love/commit/9eea3ff713c8fa0391e7b1bfa494d533dc21c0be
[3] 
https://github.com/Sabayon/systemd-love/blob/master/eclass/eselect-init.eclass

-- 
Fabio Erculiani

Re: [gentoo-dev] eselect init

[William Hubbs]

On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
 There is a new version of eselect-init in the systemd-love overlay to play 
 with.
 The new version saw the following major changes:
 
 - the /sbin/init (aka the symlink that eselect-init handles) can be
 changed to whatever one wants through make.conf [1] (this is a compile
 time option, as documented in the eclass)

Why do we need to mess with /sbin/init at all?

I like the suggestion that came up here on the list a while back, have
the eselect init module install its own symlink at, say, /sbin/einit.
You would still have to have the user edit their boot loader
configuration file one time if they want to use this, but this makes it
completely opt-in.

The other advantage of this is you don't have to mess with any  init
system ebuilds at all.

 - the wrapper and its code paths are now documented in the
 eselect-init eclass [2] [3]

This eclass could go away entirely if you don't try to control
/sbin/init.

 If you intend to use switch between systemd to openrc (and vice
 versa), make sure to install the rest of the packages in that overlay.
 At the moment, if you want to switch, you also need to use
 eselect-settingsd. However, I am planning to drop eselect-settingsd:
 openrc-settingsd and systemd share the same settingsd dbus interface
 while they call different executables, systemd initializes its dbus
 services without relying on dbus activation, so the Exec= part of the
 service descriptor file is currently set to /bin/false, this rings a
 bell :D, because it is possible to replace /bin/false with a script
 that starts the respective services when dbus activation is used
 (which means that systemd hasn't booted the system). This would make
 possible to remove the blocker dependency in openrc-settingsd and
 systemd somehow.

Keep up the good work; the more simple we can make the integration the
better it will be.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[Michał Górny]

Dnia 2013-06-20, o godz. 15:56:09
William Hubbs willi...@gentoo.org napisał(a):

 On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
  There is a new version of eselect-init in the systemd-love overlay to play 
  with.
  The new version saw the following major changes:
  
  - the /sbin/init (aka the symlink that eselect-init handles) can be
  changed to whatever one wants through make.conf [1] (this is a compile
  time option, as documented in the eclass)
 
 Why do we need to mess with /sbin/init at all?

Yes, we do because we don't want sysvinit randomly getting run
as fallback and messing with our systems.

 I like the suggestion that came up here on the list a while back, have
 the eselect init module install its own symlink at, say, /sbin/einit.
 You would still have to have the user edit their boot loader
 configuration file one time if they want to use this, but this makes it
 completely opt-in.

Plus hacking kernel sources to disable /sbin/init fallback.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[William Hubbs]

On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote:
 Dnia 2013-06-20, o godz. 15:56:09
 William Hubbs willi...@gentoo.org napisał(a):
 
  On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
   There is a new version of eselect-init in the systemd-love overlay to 
   play with.
   The new version saw the following major changes:
   
   - the /sbin/init (aka the symlink that eselect-init handles) can be
   changed to whatever one wants through make.conf [1] (this is a compile
   time option, as documented in the eclass)
  
  Why do we need to mess with /sbin/init at all?
 
 Yes, we do because we don't want sysvinit randomly getting run
 as fallback and messing with our systems.

I don't understand what you are saying here.

If eselect-init installs the wrapper as /sbin/einit, we don't have to
touch /sbin/init at all, then, the only thing someone would have to do
is to add an entry to their boot loader with init=/sbin/einit on the kcl
to use it.

  I like the suggestion that came up here on the list a while back, have
  the eselect init module install its own symlink at, say, /sbin/einit.
  You would still have to have the user edit their boot loader
  configuration file one time if they want to use this, but this makes it
  completely opt-in.
 
 Plus hacking kernel sources to disable /sbin/init fallback.

No, there is no reason we would have to hack anything in the kernel
sources.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/05/13 12:43 AM, Luca Barbato wrote:



OK -- so, given how very simple this wrapper is, and likewise how
simple the switcher script would probably be to write, what's the goal
of this whole thread, exactly?  It doesn't sound like this is
something complicated that we'd need to actually provide via an ebuild
or integrating patches in other init-system ebuilds anymore...





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGkn9QACgkQ2ugaI38ACPDo5gD/aObV6+JWdkb+qK4jR0ukh1p5
M3ITzlLVjayvAV6pixwA/2KdUeXK1xcHESVfXLcD1b7+iE75+SOKsQBZz/9S78lO
=4NET
-END PGP SIGNATURE-

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/05/13 12:43 AM, Luca Barbato wrote:
 On 5/28/13 6:19 AM, Michał Górny wrote:
 And you actually make the boot depend on:
 
 1) valid /bin/sh
 
 If it doesn't exist you have a few order of magnitude bigger 
 problem.
 
 2) valid /etc/switch-init which would not interfere with boot 
 process.
 
 I guess if you want to switch init system you need that =)
 
 With switch-init being executed as a shell script, it can do 
 anything.
 
 Yes and that's the beauty of it.
 
 And I wouldn't be surprised if you made it do various things 
 you'd like to be done.
 
 I would be surprised if I'd make it do various things I won't like 
 to be done, surely a possibility, albeit unlikely.
 


OK -- so, given how very simple this wrapper is, and likewise how
simple the switcher script would probably be to write, what's the goal
of this whole thread, exactly?  It doesn't sound like this is
something complicated that we'd need to actually provide via an ebuild
or integrating patches in other init-system ebuilds anymore...





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGkn9kACgkQ2ugaI38ACPD1bwD+IaoJ0yM2nyTt8vhICF+nzhQN
CjnLL3yU1LV9qWmwbfUA/jwO4RiTTFKHzoKLn0NHZV2ZqO1y2dbXfzWyuoxz17Lc
=oVXb
-END PGP SIGNATURE-

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 4:58 PM, Ian Stakenvicius wrote:

The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)


The really minimal wrapper would be something like

#!/bin/sh

INIT=/bin/init

if [[ -e /etc/switch-init ]]; then
. /etc/switch-init
fi

exec ${INIT}

With switch-init doing stuff needed, including remounting the rootfs rw 
if there are stuff to be changed and if we want stick to symlinks it 
could replace itself by a symlink.


Yes, it would be that simple.

lu

Re: [gentoo-dev] eselect init

[Michał Górny]

On Tue, 28 May 2013 05:55:39 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
  The way it's being proposed (and please correct me if i'm wrong), the
  wrapper is a direct replacement binary (small C program) for all init
  systems, and would based on some configuration file or whatnot
  determine and exec the init system it's supposed to -- and make any
  other necessary changes too, such as switching /etc/inittab)
 
 The really minimal wrapper would be something like
 
 #!/bin/sh
 
 INIT=/bin/init
 
 if [[ -e /etc/switch-init ]]; then
  . /etc/switch-init
 fi
 
 exec ${INIT}
 
 With switch-init doing stuff needed, including remounting the rootfs rw 
 if there are stuff to be changed and if we want stick to symlinks it 
 could replace itself by a symlink.
 
 Yes, it would be that simple.

And you actually make the boot depend on:

1) valid /bin/sh,

2) valid /etc/switch-init which would not interfere with boot process.

With switch-init being executed as a shell script, it can do anything.
And I wouldn't be surprised if you made it do various things you'd like
to be done. Not to mention what would happen if it gets corrupted into
binary mess and shell tries to execute that.

There's no fallback that could handle shell failures, you know.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/28/13 6:19 AM, Michał Górny wrote:

And you actually make the boot depend on:

1) valid /bin/sh


If it doesn't exist you have a few order of magnitude bigger problem.


2) valid /etc/switch-init which would not interfere with boot process.


I guess if you want to switch init system you need that =)


With switch-init being executed as a shell script, it can do anything.


Yes and that's the beauty of it.


And I wouldn't be surprised if you made it do various things you'd like
to be done.


I would be surprised if I'd make it do various things I won't like to be 
done, surely a possibility, albeit unlikely.



Not to mention what would happen if it gets corrupted into
binary mess and shell tries to execute that.


Having your rootfs corrupted is quite bad, even horrible if an ephemeral 
file gets corrupted through reboot.



There's no fallback that could handle shell failures, you know.


I guess your knowledge of shell needs to be expanded, beside that it is 
easier to write an example using shell pseudocode to explain how it 
could work.



That said, here a friendly suggestion: try to be less destructive in 
your comments and fix your mailer. Both can be annoying in the long run.


lu

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 - /sbin/init (or whatever linux currently calls by default with top
 priority) should be either a symlink to the actual implementation or a
 wrapper such as our gcc one. I like better the latter since it is
 overall safer. The former might or might work since linux has some
 fallback capabilities but hadn't been tested.

Increased complexity is never safer. And a wrapper means the additional
complexity gets there every boot. And considering how the discussion
goes, the wrapper will grow openrc-size in a few months...

Symlinks are simple. They're filesystem feature, they're handled
by kernel. The worst thing that could happen is symlink target
disappearing -- but then it's:

a) our responsibility to make sure to call eselect-init (if applies)
when uninstalling an init system,

b) something that would fail anyway if user did that by hand.

Linux fallback mechanism is *good enough*. You may think that fallback
to sysvinit is good but it's not. *If* I have my system set up to boot
X, at some point the config for Y will get seriously outdated.

I use systemd for a few months now, and last time I checked openrc
boots somehow. But considering the general complexity of it, I wouldn't
be much surprised if it failed in funny ways (like not being able to
handle automounts properly), caused cruft on the filesystem or even
caused *damage*.

And since you've been failing long at keeping init.d scripts simple
and reasonable, the damage potential is not something purely
theoretical.

That said, switching /sbin/init is the reasonable way. If it fails,
Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without
unexpectedly switching init system to something else just because it
was around.

 - init gets effectively switched only at boot/reboot, eselect init must
 keep track of the current active init and make sure the current init
 configuration is used till the system reboots, if we use the wrapper
 approach, it would pick up what's the new init at boot and that would be
 enough for simple cases, hooks on reboot are still needed for more
 complex ones.

Pointless and overcomplex. If an init system actually fails to work
when /sbin/init doesn't point to it, it is seriously broken by design.
And because of that breakage, we keep stuff like 'telinit' or 'reboot'
intact, and because of it systemd has 'pass-through' mode when linked
to /sbin/init.

 - we could try to not have the changes to the current init systems
 ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init)

Which means the kernel fallback will be dangerously active
as I explained before. Just don't do it.

 # FOCUS
 
 My interest is mostly if not all on bb-init-openrc and slightly on
 runit-openrc.
 
 There are enough people involved in systemd and since I still consider
 it a dangerously frail implementation of a bad idea is better if I do
 not touch it at all.

You've been able to keep this thread on topic very long. Good job!

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sat, 25 May 2013 21:52:28 -0400
Walter Dnes waltd...@waltdnes.org wrote:

 On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
 It has to be done *VERY* early at boot, or else we're back to the
 problem you described above.

Not sure what you mean with very early, you don't really have control
over this anyway; the earliest point at which you can reliably do this
is to turning init itself into a wrapper.

 It's almost like a brain surgeon operating on himself.

That's if externally you turn it into a symlink, not with a wrapper.

 1) boot into single mode before doing the changeover.  Both grub and
 lilo support single mode boot as per...
 http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode

And EFI? This sounds a bit of an overkill. What's wrong with a wrapper?

 2) have the setup/switchover mechanism built into the Gentoo minimal
 install ISO.  The advantage here is that if the system ends up no
 longer bootable off the harddrive, you can still boot from the ISO,
 chroot into the system on the harddrive, and send emails to the
 gentoo-user list asking for help G.

Users can already use eselect in their chroot.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 04:02:56 +0200
Peter Stuge pe...@stuge.se wrote:

 By take effect I mean that the filesystem should be modified in such
 a way that the next boot will use what I selected. No further action
 which could fail should be required beyond the eselect command.
 
 Unless the eselect command has successfully modified the filesystem I
 can't really know that my system will boot with what I have selected,
 ie. eselect does not provide any useful feedback, because it can not.

That's exactly what I've described in another mail in another subthread.

http://thread.gmane.org/gmane.linux.gentoo.devel/85778/focus=85789

Snippet of what I said:

 Sounds like we would have two files like 'current_init' and
 'boot_init' and `eselect init ...` would update 'boot_init'. Then,
 the first `init` invocation on boot would update 'current_init' with
 the value of 'boot_init'; latter `init` invocations can then read out
 'current_init', which is not to be touched by `eselect init ...`.

This assumes that you would be working with a wrapper, not a symlink.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Robert David]

On Sun, 26 May 2013 08:43:32 +0200
Michał Górny mgo...@gentoo.org wrote:

 On Sat, 25 May 2013 11:54:48 +0200
 Luca Barbato lu_z...@gentoo.org wrote:
 
  - /sbin/init (or whatever linux currently calls by default with top
  priority) should be either a symlink to the actual implementation
  or a wrapper such as our gcc one. I like better the latter since it
  is overall safer. The former might or might work since linux has
  some fallback capabilities but hadn't been tested.
 
 Increased complexity is never safer. And a wrapper means the
 additional complexity gets there every boot. And considering how the
 discussion goes, the wrapper will grow openrc-size in a few months...
 
 Symlinks are simple. They're filesystem feature, they're handled
 by kernel. The worst thing that could happen is symlink target
 disappearing -- but then it's:
 
 a) our responsibility to make sure to call eselect-init (if applies)
 when uninstalling an init system,
 
 b) something that would fail anyway if user did that by hand.
 
 Linux fallback mechanism is *good enough*. You may think that fallback
 to sysvinit is good but it's not. *If* I have my system set up to boot
 X, at some point the config for Y will get seriously outdated.
 
 I use systemd for a few months now, and last time I checked openrc
 boots somehow. But considering the general complexity of it, I
 wouldn't be much surprised if it failed in funny ways (like not being
 able to handle automounts properly), caused cruft on the filesystem
 or even caused *damage*.
 
 And since you've been failing long at keeping init.d scripts simple
 and reasonable, the damage potential is not something purely
 theoretical.
 
 That said, switching /sbin/init is the reasonable way. If it fails,
 Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without
 unexpectedly switching init system to something else just because it
 was around.

I agree with this. But changing symlinks is not as easy on running
system (since it can cause inconsistence during rebooot). I think that
safest way not using wrapper is to stop all services and keep only
mounted /, than change things (symlinks,configuration update) and
reboot. 

Thus this eselect init will let the user confirm and then trigger
reboot. I do not think that users will change init all the time, thus
make it better safe and more complex in this change is better than
check and wrap in all the boots.

Otherwise interesting is preinit handler in OpenWrt:
http://wiki.openwrt.org/doc/techref/process.boot
http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit
http://wiki.openwrt.org/doc/techref/preinit_mount

Robert.

 
  - init gets effectively switched only at boot/reboot, eselect init
  must keep track of the current active init and make sure the
  current init configuration is used till the system reboots, if we
  use the wrapper approach, it would pick up what's the new init at
  boot and that would be enough for simple cases, hooks on reboot are
  still needed for more complex ones.
 
 Pointless and overcomplex. If an init system actually fails to work
 when /sbin/init doesn't point to it, it is seriously broken by design.
 And because of that breakage, we keep stuff like 'telinit' or 'reboot'
 intact, and because of it systemd has 'pass-through' mode when linked
 to /sbin/init.
 
  - we could try to not have the changes to the current init systems
  ebuild or reduce them to the bare minimum (e.g. not
  overwrite /sbin/init)
 
 Which means the kernel fallback will be dangerously active
 as I explained before. Just don't do it.
 
  # FOCUS
  
  My interest is mostly if not all on bb-init-openrc and slightly on
  runit-openrc.
  
  There are enough people involved in systemd and since I still
  consider it a dangerously frail implementation of a bad idea is
  better if I do not touch it at all.
 
 You've been able to keep this thread on topic very long. Good job!
 

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 10:58:23 +0200
Robert David robert.david.pub...@gmail.com wrote:

 On Sun, 26 May 2013 08:43:32 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  On Sat, 25 May 2013 11:54:48 +0200
  Luca Barbato lu_z...@gentoo.org wrote:
  
   - /sbin/init (or whatever linux currently calls by default with top
   priority) should be either a symlink to the actual implementation
   or a wrapper such as our gcc one. I like better the latter since it
   is overall safer. The former might or might work since linux has
   some fallback capabilities but hadn't been tested.
  
  Increased complexity is never safer. And a wrapper means the
  additional complexity gets there every boot. And considering how the
  discussion goes, the wrapper will grow openrc-size in a few months...
  
  Symlinks are simple. They're filesystem feature, they're handled
  by kernel. The worst thing that could happen is symlink target
  disappearing -- but then it's:
  
  a) our responsibility to make sure to call eselect-init (if applies)
  when uninstalling an init system,
  
  b) something that would fail anyway if user did that by hand.
  
  Linux fallback mechanism is *good enough*. You may think that fallback
  to sysvinit is good but it's not. *If* I have my system set up to boot
  X, at some point the config for Y will get seriously outdated.
  
  I use systemd for a few months now, and last time I checked openrc
  boots somehow. But considering the general complexity of it, I
  wouldn't be much surprised if it failed in funny ways (like not being
  able to handle automounts properly), caused cruft on the filesystem
  or even caused *damage*.
  
  And since you've been failing long at keeping init.d scripts simple
  and reasonable, the damage potential is not something purely
  theoretical.
  
  That said, switching /sbin/init is the reasonable way. If it fails,
  Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without
  unexpectedly switching init system to something else just because it
  was around.
 
 I agree with this. But changing symlinks is not as easy on running
 system (since it can cause inconsistence during rebooot).

It is *easy*.

  ln -s /sbin/newinit /sbin/init.new
  mv /sbin/init.new /sbin/init

Easy and atomic. The inconsistency potential is similar to one given by
init upgrades. Yet we don't do anything magical to defer init upgrade
until reboot, and that's why the upgrades go smoothly.

 I think that safest way not using wrapper is to stop all services
 and keep only mounted /, than change things (symlinks,configuration
 update) and reboot. 

This can be done two ways.

One is hacking into init (RC) reboot procedure. It's fragile, it needs
to be fit into the right moment and I'm not sure if all inits will
handle this without actually needing to patch the code. And in the end,
the init gets replaced before init stops working anyway.

The other is going beside init and directly into the reboot. This
either requires kernel hacking (please don't!) or hacking the reboot
procedure in init code. And of course remounting R/W, then writing,
remounting back...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 10:58:23 +0200
Robert David robert.david.pub...@gmail.com wrote:

  Increased complexity is never safer. And a wrapper means the
  additional complexity gets there every boot. And considering how
  the discussion goes, the wrapper will grow openrc-size in a few
  months..

 I agree with this. But changing symlinks is not as easy on running
 system (since it can cause inconsistence during rebooot). I think that
 safest way not using wrapper is to stop all services and keep only
 mounted /, than change things (symlinks,configuration update) and
 reboot. 
 
 Thus this eselect init will let the user confirm and then trigger
 reboot. I do not think that users will change init all the time, thus
 make it better safe and more complex in this change is better than
 check and wrap in all the boots.
 
 Otherwise interesting is preinit handler in OpenWrt:
 http://wiki.openwrt.org/doc/techref/process.boot
 http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit
 http://wiki.openwrt.org/doc/techref/preinit_mount

In other words, if you go for the symlink approach you're just moving
complexity to your system instead of into the boot; I don't see why a
wrapper would grow to openrc size, that's just a bold exaggeration.

I'd rather have a clean wrapper that just works than an unclean way to
cover the reboot madness that comes along; forcing a reboot, really?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Robert David]

On Sun, 26 May 2013 11:20:25 +0200
Michał Górny mgo...@gentoo.org wrote:

 On Sun, 26 May 2013 10:58:23 +0200
 Robert David robert.david.pub...@gmail.com wrote:
 
  On Sun, 26 May 2013 08:43:32 +0200
  Michał Górny mgo...@gentoo.org wrote:
  
   On Sat, 25 May 2013 11:54:48 +0200
   Luca Barbato lu_z...@gentoo.org wrote:
   
- /sbin/init (or whatever linux currently calls by default with
top priority) should be either a symlink to the actual
implementation or a wrapper such as our gcc one. I like better
the latter since it is overall safer. The former might or might
work since linux has some fallback capabilities but hadn't been
tested.
   
   Increased complexity is never safer. And a wrapper means the
   additional complexity gets there every boot. And considering how
   the discussion goes, the wrapper will grow openrc-size in a few
   months...
   
   Symlinks are simple. They're filesystem feature, they're handled
   by kernel. The worst thing that could happen is symlink target
   disappearing -- but then it's:
   
   a) our responsibility to make sure to call eselect-init (if
   applies) when uninstalling an init system,
   
   b) something that would fail anyway if user did that by hand.
   
   Linux fallback mechanism is *good enough*. You may think that
   fallback to sysvinit is good but it's not. *If* I have my system
   set up to boot X, at some point the config for Y will get
   seriously outdated.
   
   I use systemd for a few months now, and last time I checked openrc
   boots somehow. But considering the general complexity of it, I
   wouldn't be much surprised if it failed in funny ways (like not
   being able to handle automounts properly), caused cruft on the
   filesystem or even caused *damage*.
   
   And since you've been failing long at keeping init.d scripts
   simple and reasonable, the damage potential is not something
   purely theoretical.
   
   That said, switching /sbin/init is the reasonable way. If it
   fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you
   like. Without unexpectedly switching init system to something
   else just because it was around.
  
  I agree with this. But changing symlinks is not as easy on running
  system (since it can cause inconsistence during rebooot).
 
 It is *easy*.
 
   ln -s /sbin/newinit /sbin/init.new
   mv /sbin/init.new /sbin/init
 
 Easy and atomic. The inconsistency potential is similar to one given
 by init upgrades. Yet we don't do anything magical to defer init
 upgrade until reboot, and that's why the upgrades go smoothly.

You are right. Even though, it is highly appreciated to inform user on
urgent reboot. 

 
  I think that safest way not using wrapper is to stop all services
  and keep only mounted /, than change things (symlinks,configuration
  update) and reboot. 
 
 This can be done two ways.
 
 One is hacking into init (RC) reboot procedure. It's fragile, it needs
 to be fit into the right moment and I'm not sure if all inits will
 handle this without actually needing to patch the code. And in the
 end, the init gets replaced before init stops working anyway.
 
 The other is going beside init and directly into the reboot. This
 either requires kernel hacking (please don't!) or hacking the reboot
 procedure in init code. And of course remounting R/W, then writing,
 remounting back...
 

I did not say it will be easy. Still I think there is space to
investigate deeply how to handle that more cleanly (eg: onetime late
shutdonw initscript/unit). No one will be hacking kernel:)

Robert.

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 11:20:25 +0200
Michał Górny mgo...@gentoo.org wrote:

 It is *easy*.
 
   ln -s /sbin/newinit /sbin/init.new
   mv /sbin/init.new /sbin/init

 Easy and atomic. The inconsistency potential is similar to one given
 by init upgrades. Yet we don't do anything magical to defer init
 upgrade until reboot, and that's why the upgrades go smoothly.

Easy isn't always good. It's not atomic since you can't reboot and
because of that I wouldn't call it smooth either.

  I think that safest way not using wrapper is to stop all services
  and keep only mounted /, than change things (symlinks,configuration
  update) and reboot. 
 
 This can be done two ways.
 
 One is hacking into init (RC) reboot procedure. It's fragile, it needs
 to be fit into the right moment and I'm not sure if all inits will
 handle this without actually needing to patch the code. And in the
 end, the init gets replaced before init stops working anyway.

You're making things way more complex than a wrapper would do. I'm not
a fan of using the words hacking, fragile and not sure for
selling an approach; so, why were you suggesting the symlink approach?

 The other is going beside init and directly into the reboot. This
 either requires kernel hacking (please don't!)

Yes, please don't, it's against our general objectives.

http://www.gentoo.org/proj/en/kernel/maintenance.xml#doc_chap3

Furthermore, even if you would consider this then you can't be
guaranteed that everyone uses genpatches; and I don't think we would
want this in the eclass either, its users will very likely object.

 or hacking the reboot procedure in init code. And of course
 remounting R/W, then writing, remounting back...

I don't think patching them is a reliable approach; it steps away from
being loosely coupled and therefore makes it harder to understand, you
are changing multiple things at once and introduce a maintenance burden.

With a wrapper, you don't have a problem with any of those...

Loose coupling, high cohesion.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 8:43 AM, Michał Górny wrote:

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:


- /sbin/init (or whatever linux currently calls by default with top
priority) should be either a symlink to the actual implementation or a
wrapper such as our gcc one. I like better the latter since it is
overall safer. The former might or might work since linux has some
fallback capabilities but hadn't been tested.


Increased complexity is never safer. And a wrapper means the additional
complexity gets there every boot. And considering how the discussion
goes, the wrapper will grow openrc-size in a few months...


Openrc is small, but the wrapper really needs to know which is which and 
worst case switch inittab.



Symlinks are simple. They're filesystem feature, they're handled
by kernel. The worst thing that could happen is symlink target
disappearing -- but then it's:

a) our responsibility to make sure to call eselect-init (if applies)
when uninstalling an init system,

b) something that would fail anyway if user did that by hand.

Linux fallback mechanism is *good enough*. You may think that fallback
to sysvinit is good but it's not. *If* I have my system set up to boot
X, at some point the config for Y will get seriously outdated.


Have you tested it? Do you know what is the reaction of do_exec on a 
dangling symlink?



I use systemd for a few months now, and last time I checked openrc
boots somehow. But considering the general complexity of it, I wouldn't
be much surprised if it failed in funny ways (like not being able to
handle automounts properly), caused cruft on the filesystem or even
caused *damage*.


openrc is *simpler* much *simpler* than systemd, stop with that.


And since you've been failing long at keeping init.d scripts simple
and reasonable, the damage potential is not something purely
theoretical.


wc -l is a good answer to your concern. Some scripts have to be 
simplified, that's a given (e.g. Fabio pointed the lvm one can be 
improved a lot) but it isn't the case for most of them.



Pointless and overcomplex. If an init system actually fails to work
when /sbin/init doesn't point to it, it is seriously broken by design.
And because of that breakage, we keep stuff like 'telinit' or 'reboot'
intact, and because of it systemd has 'pass-through' mode when linked
to /sbin/init.


Check your facts, systemd either understands a flavour of inittab or the 
other or none at all.



Which means the kernel fallback will be dangerously active
as I explained before. Just don't do it.


It is not dangerous beside for those that have an inittab with rm -fR /

lu

Re: [gentoo-dev] eselect init

[Robert David]

On Sun, 26 May 2013 11:21:25 +0200
Tom Wijsman tom...@gentoo.org wrote:

 On Sun, 26 May 2013 10:58:23 +0200
 Robert David robert.david.pub...@gmail.com wrote:
 
   Increased complexity is never safer. And a wrapper means the
   additional complexity gets there every boot. And considering how
   the discussion goes, the wrapper will grow openrc-size in a few
   months..
 
  I agree with this. But changing symlinks is not as easy on running
  system (since it can cause inconsistence during rebooot). I think
  that safest way not using wrapper is to stop all services and keep
  only mounted /, than change things (symlinks,configuration update)
  and reboot. 
  
  Thus this eselect init will let the user confirm and then trigger
  reboot. I do not think that users will change init all the time,
  thus make it better safe and more complex in this change is better
  than check and wrap in all the boots.
  
  Otherwise interesting is preinit handler in OpenWrt:
  http://wiki.openwrt.org/doc/techref/process.boot
  http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit
  http://wiki.openwrt.org/doc/techref/preinit_mount
 
 In other words, if you go for the symlink approach you're just moving
 complexity to your system instead of into the boot; I don't see why a
 wrapper would grow to openrc size, that's just a bold exaggeration.

Newer say that wrapper will grow openrc size, and also dont know why it
would be bad. The point is somewhere else. I really dont know how many
user will switch inits and how many of them will do this regularly.
But the wrapper will be executed every boot. So even a tiny mistake
can produce booting problems even for those who did not wanted to
change anything in init process. On the other hand mistake in some
system process will affect only those who would actually switching. It
is only calculation of possible risks.

I also did not say it must be done the reboot way I mentioned, this is
only and different point what can be though about. 

 
 I'd rather have a clean wrapper that just works than an unclean way to
 cover the reboot madness that comes along; forcing a reboot, really?
 

I do not see point not forcing reboot when I'm switching init, or let
say suggesting. When you update your kernel config, rebuild and
install you also can stay working, but you have to be prepared to have
nonworking modules that was not inserted before.

Re: [gentoo-dev] eselect init

[Rich Freeman]

On Sun, May 26, 2013 at 6:01 AM, Robert David
robert.david.pub...@gmail.com wrote:
 Newer say that wrapper will grow openrc size, and also dont know why it
 would be bad. The point is somewhere else. I really dont know how many
 user will switch inits and how many of them will do this regularly.
 But the wrapper will be executed every boot. So even a tiny mistake
 can produce booting problems even for those who did not wanted to
 change anything in init process. On the other hand mistake in some
 system process will affect only those who would actually switching. It
 is only calculation of possible risks.

You can have your cake and eat it too.  Just don't call the wrapper
init.  Somebody else already suggested leaving the init
implementations alone and stick the wrapper in a new binary that would
need to be enabled specifically in the boot/kernel configuration.

So if grub points to /sbin/einit then it runs the wrapper.  If it just
points to openrc/systemd then it directly executes them and bypasses
the wrapper.  That means that this whole thing only impacts those who
install it, which is the best way to implement something experimental
in the first place.

Granted, I don't know the limitations of the EFI bootloaders that are
out there, but this still seems like something better solved via grub
configuration.  When I implemented systemd in one of my VMs I just
added a grub line to boot back to openrc.

Rich

Re: [gentoo-dev] eselect init

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
 Granted, I don't know the limitations of the EFI bootloaders that are
 out there, but this still seems like something better solved via grub
 configuration.  When I implemented systemd in one of my VMs I just
 added a grub line to boot back to openrc.

EFI stub kernels just need init=/sbin/wrappername in CONFIG_CMDLINE in
order to use the wrapper.
However, in case of breakage in the wrapper, you would need to boot a
fallback kernel or access the EFI shell (not all UEFI implementations allow
the latter).


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 Openrc is small, but the wrapper really needs to know which is which

It doesn't need to, it just needs to kick off the right init process.

If you think it does need to, please elaborate.

 and worst case switch inittab.

You could keep this kind of logic outside the wrapper, specific to the
init system; such that the wrapper and therefore the shared part of the
boot regardless of init system stays as small as possible.

This could be even something you could let the eselect script change,
the inittab is only needed at boot time as far as I can recall.

 openrc is *simpler* much *simpler* than systemd, stop with that.

Simpler is not necessarily better, stop with flames you don't back up;
and if you do back them up, then please keep it outside of the ML.

You're contributing to sidetracking your own discussion.

  And since you've been failing long at keeping init.d scripts simple
  and reasonable, the damage potential is not something purely
  theoretical.
 
 wc -l is a good answer to your concern. Some scripts have to be 
 simplified, that's a given (e.g. Fabio pointed the lvm one can be 
 improved a lot) but it isn't the case for most of them.

If we're really going to have this discussion and you really care
about wc -l, maybe we should compress init scripts and service units;
perhaps we could then combine them into one file to spare inodes too.

Joke aside; the other reason, maintainability, is a good one.

 It is not dangerous beside for those that have an inittab with rm
 -fR /

Root preservation should make this safe.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 On 5/26/13 8:43 AM, Michał Górny wrote:
  On Sat, 25 May 2013 11:54:48 +0200
  Luca Barbato lu_z...@gentoo.org wrote:
 
  - /sbin/init (or whatever linux currently calls by default with top
  priority) should be either a symlink to the actual implementation or a
  wrapper such as our gcc one. I like better the latter since it is
  overall safer. The former might or might work since linux has some
  fallback capabilities but hadn't been tested.
 
  Increased complexity is never safer. And a wrapper means the additional
  complexity gets there every boot. And considering how the discussion
  goes, the wrapper will grow openrc-size in a few months...
 
 Openrc is small, but the wrapper really needs to know which is which and 
 worst case switch inittab.

Switch inittab? Now you added really dangerous behavior to the wrapper
code. I can hardly even express this in words.

You are telling me that a wrapper, a thing that gets executed *every*
boot needs to do some random magic to know which init system was in use
and which one is supposed to be in use, and then conditionally move
around configuration files necessary for it to run. This is just
*INSANE*.

Did anyone notice already that moving stuff around actually requires
rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
of init/RC work.

And what will happen if moving the files fail? What if half of
configuration belongs to old init, and half to new? And it all happens
automagically on boot, on an incomplete system without any console
started, without Internet connection established and without any
serious mean of help.

  Symlinks are simple. They're filesystem feature, they're handled
  by kernel. The worst thing that could happen is symlink target
  disappearing -- but then it's:
 
  a) our responsibility to make sure to call eselect-init (if applies)
  when uninstalling an init system,
 
  b) something that would fail anyway if user did that by hand.
 
  Linux fallback mechanism is *good enough*. You may think that fallback
  to sysvinit is good but it's not. *If* I have my system set up to boot
  X, at some point the config for Y will get seriously outdated.
 
 Have you tested it? Do you know what is the reaction of do_exec on a 
 dangling symlink?

And did you? You keep repeating this and jumping straight to developing
work-arounds without even waiting for an answer. And I think William
has already spoken that the code supports it.

In any case, I've just tested it. Replaced /sbin/init with a dangling
symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh
as a fallback.

  I use systemd for a few months now, and last time I checked openrc
  boots somehow. But considering the general complexity of it, I wouldn't
  be much surprised if it failed in funny ways (like not being able to
  handle automounts properly), caused cruft on the filesystem or even
  caused *damage*.
 
 openrc is *simpler* much *simpler* than systemd, stop with that.

OpenRC relies on a few layers of various tools plus a lot of init
scripts written by different people. Those init scripts include tasks
such as parsing configuration files (well, more of grepping them)
and manipulating runtime files. The complexity of OpenRC is the sum
of all that.

To make this point cleaner to you: what if the fallback ran systemd
instead? As in, init gets broken somehow and kernel falls back to
starting systemd on your unprepared OpenRC system. Is this a behavior
you'd like?

What I'm telling is: if user uses A as init system (and wanted to switch
to B), last thing he'd expect is C being started. Configuration for
OpenRC may be long unmaintained, may start services which are not
supposed to be started anymore and so on.

  And since you've been failing long at keeping init.d scripts simple
  and reasonable, the damage potential is not something purely
  theoretical.
 
 wc -l is a good answer to your concern. Some scripts have to be 
 simplified, that's a given (e.g. Fabio pointed the lvm one can be 
 improved a lot) but it isn't the case for most of them.

We're not talking about percentages here. A *single* fragile script is
enough to cause trouble. Ten good ones won't revert it.

  Pointless and overcomplex. If an init system actually fails to work
  when /sbin/init doesn't point to it, it is seriously broken by design.
  And because of that breakage, we keep stuff like 'telinit' or 'reboot'
  intact, and because of it systemd has 'pass-through' mode when linked
  to /sbin/init.
 
 Check your facts, systemd either understands a flavour of inittab or the 
 other or none at all.

What are you talking about now? I was just saying that *if* you
link /sbin/init to systemd, and you're running sysvinit, 'init foo'
will be passed through to telinit.

But now I see that I was wrong and it actually happened when
'systemctl' was symlinked to 'init'. Nevermind then.

In any case, keeping all the tools like 

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 11:45:38 +0200
Tom Wijsman tom...@gentoo.org wrote:

 On Sun, 26 May 2013 11:20:25 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  It is *easy*.
  
ln -s /sbin/newinit /sbin/init.new
mv /sbin/init.new /sbin/init
 
  Easy and atomic. The inconsistency potential is similar to one given
  by init upgrades. Yet we don't do anything magical to defer init
  upgrade until reboot, and that's why the upgrades go smoothly.
 
 Easy isn't always good. It's not atomic since you can't reboot and
 because of that I wouldn't call it smooth either.

Can't you? How come?

   I think that safest way not using wrapper is to stop all services
   and keep only mounted /, than change things (symlinks,configuration
   update) and reboot. 
  
  This can be done two ways.
  
  One is hacking into init (RC) reboot procedure. It's fragile, it needs
  to be fit into the right moment and I'm not sure if all inits will
  handle this without actually needing to patch the code. And in the
  end, the init gets replaced before init stops working anyway.
 
 You're making things way more complex than a wrapper would do. I'm not
 a fan of using the words hacking, fragile and not sure for
 selling an approach; so, why were you suggesting the symlink approach?

Don't mix the two mails. I am showing how fragile the solution
suggested by Robert is. While you seem to be replying to every mail
possible to repeatedly advocate your idea.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[hasufell]

On 05/26/2013 12:11 PM, Rich Freeman wrote:
 That means that this whole thing only impacts those who
 install it, which is the best way to implement something experimental
 in the first place.
 

+1

I and probably a lot of other people have zero interest in this
approach, so we should not be bothered with testing/configuring/using it.

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 12:57 PM, Michał Górny wrote:

On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato lu_z...@gentoo.org wrote:


On 5/26/13 8:43 AM, Michał Górny wrote:

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:


- /sbin/init (or whatever linux currently calls by default with top
priority) should be either a symlink to the actual implementation or a
wrapper such as our gcc one. I like better the latter since it is
overall safer. The former might or might work since linux has some
fallback capabilities but hadn't been tested.


Increased complexity is never safer. And a wrapper means the additional
complexity gets there every boot. And considering how the discussion
goes, the wrapper will grow openrc-size in a few months...


Openrc is small, but the wrapper really needs to know which is which and
worst case switch inittab.


Switch inittab? Now you added really dangerous behavior to the wrapper
code. I can hardly even express this in words.


I need it for my purpose, bb-init syntax isn't the same as sysv.


You are telling me that a wrapper, a thing that gets executed *every*
boot needs to do some random magic to know which init system was in use
and which one is supposed to be in use, and then conditionally move
around configuration files necessary for it to run. This is just
*INSANE*.


I like to think it normal and the wrapper doesn't need to run every time 
but only when a switch had been requested. And only if you prefer doing 
the switch at boot time instead than at shutdown.



Did anyone notice already that moving stuff around actually requires
rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
of init/RC work.


Noticed and known issue, I merely stated which are the options on the 
plate, keep in mind that init addons people use and we distribute do 
even more evil stuff.



And what will happen if moving the files fail? What if half of
configuration belongs to old init, and half to new? And it all happens
automagically on boot, on an incomplete system without any console
started, without Internet connection established and without any
serious mean of help.


You can:

- consider rolling back
- drop to a shell

Nothing so terrible.


And did you? You keep repeating this and jumping straight to developing
work-arounds without even waiting for an answer. And I think William
has already spoken that the code supports it.


I read the code up to do_exec, given for me it would require have a 
roundtrip to the efi shell I was hoping those proposing that would do 
that basic homework =)



In any case, I've just tested it. Replaced /sbin/init with a dangling
symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh
as a fallback.


That's all I wanted everybody knows, thanks for helping.


OpenRC relies on a few layers of various tools plus a lot of init
scripts written by different people. Those init scripts include tasks
such as parsing configuration files (well, more of grepping them)
and manipulating runtime files. The complexity of OpenRC is the sum
of all that.


I read it as as complex as the user wants.


To make this point cleaner to you: what if the fallback ran systemd
instead? As in, init gets broken somehow and kernel falls back to
starting systemd on your unprepared OpenRC system. Is this a behavior
you'd like?


I would expect any sane init would get me at least to their single mode.


What I'm telling is: if user uses A as init system (and wanted to switch
to B), last thing he'd expect is C being started. Configuration for
OpenRC may be long unmaintained, may start services which are not
supposed to be started anymore and so on.


The safest would be dropping to a shell in your scenario.

As I stated from start the switch on boot would work so the wrapper 
checks a switch had been requested, it knows the current init, that must 
work since worked the previous boot, the next init, that supposedly 
should work, does the pivoting, shuffling and such and the next boot it 
just hands over to the current init.


The wrapper could even install and uninstall itself.

Again, my object of interest is being able to use bb-init and runit.


We're not talking about percentages here. A *single* fragile script is
enough to cause trouble. Ten good ones won't revert it.


A single fragile script can be fixed I guess, which is the one you have 
in mind that is concerning?



What are you talking about now? I was just saying that *if* you
link /sbin/init to systemd, and you're running sysvinit, 'init foo'
will be passed through to telinit.

But now I see that I was wrong and it actually happened when
'systemctl' was symlinked to 'init'. Nevermind then.

In any case, keeping all the tools like 'telinit' should be *enough* to
keep the current init running and rebooting.


You are focused on systemd, I'm focused on bb-init among the rest, it 
uses a different syntax for the inittab, so if you want to switch from 
one or another you either prepare a 

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 12:09:21 +0200
Michał Górny mgo...@gentoo.org wrote:

  Easy isn't always good. It's not atomic since you can't reboot and
  because of that I wouldn't call it smooth either.
 
 Can't you? How come?

Because it expects the init system you boot with to be present.

I think that safest way not using wrapper is to stop all
services and keep only mounted /, than change things
(symlinks,configuration update) and reboot. 
   
   This can be done two ways.
   
   One is hacking into init (RC) reboot procedure. It's fragile, it
   needs to be fit into the right moment and I'm not sure if all
   inits will handle this without actually needing to patch the
   code. And in the end, the init gets replaced before init stops
   working anyway.
  
  You're making things way more complex than a wrapper would do. I'm
  not a fan of using the words hacking, fragile and not sure for
  selling an approach; so, why were you suggesting the symlink
  approach?
 
 Don't mix the two mails.

Don't read it as mixed, it is not; I take it that you agree with me as
you choose not to answer to it. If you meant to advocate your own
solution, expanding the other solutions is going to make us forget
about what you were suggesting; you're creating your own mixture.

 I am showing how fragile the solution suggested by Robert is. While
 you seem to be replying to every mail possible to repeatedly advocate
 your idea.

And I am showing how fragile your expansions to Robert's solution are;
thanks for clarifying you meant to point out its fragile, that was not
entirely clear from your response and I assumed another intention.

We are on the same line here, in fact you have replied more in this sub
thread than I did. The wrapper is not my idea; despites my advocation...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 12:57:42 +0200
Michał Górny mgo...@gentoo.org wrote:

 Switch inittab? Now you added really dangerous behavior to the wrapper
 code. I can hardly even express this in words.

It doesn't need to be in the wrapper, inittab is something read at boot
only as far as I am aware and therefore eselect can do it.

 You are telling me that a wrapper, a thing that gets executed *every*
 boot needs to do some random magic to know which init system was in
 use and which one is supposed to be in use, and then conditionally
 move around configuration files necessary for it to run. This is just
 *INSANE*.

 Did anyone notice already that moving stuff around actually requires
 rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
 of init/RC work.

The wrapper only needs to read stuff, I see no reason for it to write
stuff. It needs to read which init it needs to kick off, nothing more
than that; if more is needed, please elaborate in full detail.
 
 And what will happen if moving the files fail?

Which files? Since eselect would move them, we would be aware that it
failed and could possibly rollback.

 What if half of configuration belongs to old init, and half to new?

Given a rollback, I don't see this happen; unless the rollback fails...

 And it all happens automagically on boot, on an incomplete system
 without any console started, without Internet connection established
 and without any serious mean of help.

Barely anything needs to happen on boot, stop adding complexity; the
wrapper is meant to be simple, not another init system on its own.

People are having way to different ideas about the wrapper, this is not
good; I think people should start to express their ideas in documents,
same with the symlink solutions. These everything in the wrapper,
everything on reboot assumptions are running out of hand.

   I use systemd for a few months now, and last time I checked openrc
   boots somehow. But considering the general complexity of it, I
   wouldn't be much surprised if it failed in funny ways (like not
   being able to handle automounts properly), caused cruft on the
   filesystem or even caused *damage*.
  
  openrc is *simpler* much *simpler* than systemd, stop with that.
 
 [SNIP]
 
 To make this point cleaner to you: what if the fallback ran systemd
 instead? 
 
 [SNIP]

Why should the fallback be different from what stage3 provides?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 13:45:43 +0200
Tom Wijsman tom...@gentoo.org wrote:

 On Sun, 26 May 2013 12:09:21 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
   Easy isn't always good. It's not atomic since you can't reboot and
   because of that I wouldn't call it smooth either.
  
  Can't you? How come?
 
 Because it expects the init system you boot with to be present.

And it is present. It's just the symlink what differs. The symlink
should be used just to boot the init and for nothing more. The booted
init should be able to find itself.

If it isn't, it's the init's what needs to be fixed. Really.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 13:40:03 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 On 5/26/13 12:57 PM, Michał Górny wrote:
  Switch inittab? Now you added really dangerous behavior to the wrapper
  code. I can hardly even express this in words.
 
 I need it for my purpose, bb-init syntax isn't the same as sysv.

Then you need to use a different file. Feel free to rename either
inittab but don't even think of switching files like this.

  You are telling me that a wrapper, a thing that gets executed *every*
  boot needs to do some random magic to know which init system was in use
  and which one is supposed to be in use, and then conditionally move
  around configuration files necessary for it to run. This is just
  *INSANE*.
 
 I like to think it normal and the wrapper doesn't need to run every time 
 but only when a switch had been requested. And only if you prefer doing 
 the switch at boot time instead than at shutdown.

Well, that makes it a bit less destructive. Though I still don't like
the idea.

  And what will happen if moving the files fail? What if half of
  configuration belongs to old init, and half to new? And it all happens
  automagically on boot, on an incomplete system without any console
  started, without Internet connection established and without any
  serious mean of help.
 
 You can:
 
 - consider rolling back
 - drop to a shell
 
 Nothing so terrible.

Sounds like an initramfs...

  What I'm telling is: if user uses A as init system (and wanted to switch
  to B), last thing he'd expect is C being started. Configuration for
  OpenRC may be long unmaintained, may start services which are not
  supposed to be started anymore and so on.
 
 The safest would be dropping to a shell in your scenario.
 
 As I stated from start the switch on boot would work so the wrapper 
 checks a switch had been requested, it knows the current init, that must 
 work since worked the previous boot, the next init, that supposedly 
 should work, does the pivoting, shuffling and such and the next boot it 
 just hands over to the current init.

It all depends on how it is implemented. If we decide not to
touch /sbin/init, then sysvinit will be the effective fallback at some
earlier or later point, depending on what will fail. This is what I
really dislike.

  We're not talking about percentages here. A *single* fragile script is
  enough to cause trouble. Ten good ones won't revert it.
 
 A single fragile script can be fixed I guess, which is the one you have 
 in mind that is concerning?

You could've asked me that when I was still using OpenRC. I don't
really want to grep the 40 scripts right now, and I don't think I have
the worse cases installed here.

  What are you talking about now? I was just saying that *if* you
  link /sbin/init to systemd, and you're running sysvinit, 'init foo'
  will be passed through to telinit.
 
  But now I see that I was wrong and it actually happened when
  'systemctl' was symlinked to 'init'. Nevermind then.
 
  In any case, keeping all the tools like 'telinit' should be *enough* to
  keep the current init running and rebooting.
 
 You are focused on systemd, I'm focused on bb-init among the rest, it 
 uses a different syntax for the inittab, so if you want to switch from 
 one or another you either prepare a least-action script that switch the 
 inittab on reboot or a first-action script that does that on boot.
 
 For your needs probably just pivoting a symlink should work almost fine, 
 as long your stay sysvinit compatible, yet doing that as early init or 
 as post kill-all should work better even in your case.

Well, you're transforming a simple idea with potentially relatively
wide audience into a horror story with a single user.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 12:01:19 +0200
Robert David robert.david.pub...@gmail.com wrote:

 Newer say that wrapper will grow openrc size, and also dont know why
 it would be bad.

That's what I'd like to know from him, I was quoting both of you,

 I really dont know how many user will switch inits and how many of
 them will do this regularly.

Users that would like to compare things, users that are bothered by one
init system and try to try an alternative one; developers that want to
test both init scripts and service units and thus need to change often,
people that would want a specific init system but haven't found out how
to switch properly to it yet. I think there are more than a hand full.

 But the wrapper will be executed every boot. So even a tiny mistake
 can produce booting problems even for those who did not wanted to
 change anything in init process.

One would properly test the wrapper, perhaps even have multiple members
of arch teams test it, before bringing this out to the user base; it's
a very critical matter and we can indeed not afford a mistake here.
That being said, once the wrapper is in place and works; I don't think
we need to touch it often, it's just a wrapper after all. Do other
wrappers, desktop files and files of similar nature we use around
Gentoo change often; I think not.

 On the other hand mistake in some system process will affect only
 those who would actually switching. It is only calculation of
 possible risks.

If you do risk assessment, you should count in all risks; that
therefore also means to take maintainability into account. See my other
mail about what it takes to step away from a loosely coupled approach.

 I also did not say it must be done the reboot way I mentioned, this is
 only and different point what can be though about. 

And we're thinking it through, I don't see why you mention this; I can
understand that you don't necessarily stand behind it though, that's OK.

  
  I'd rather have a clean wrapper that just works than an unclean way
  to cover the reboot madness that comes along; forcing a reboot,
  really?
  
 
 I do not see point not forcing reboot when I'm switching init, or let
 say suggesting. When you update your kernel config, rebuild and
 install you also can stay working, but you have to be prepared to have
 nonworking modules that was not inserted before.

My point was that with a wrapper you don't need to force this; the
modules problem is irrelevant to this discussion, I don't see any
problem in that light with the approaches we are discussing here.

PS: If this message ends up in a separate thread, it's because I'm
forwarding it from my Sent mail because there was no reply-to present.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 2:08 PM, Michał Górny wrote:

You could've asked me that when I was still using OpenRC. I don't
really want to grep the 40 scripts right now, and I don't think I have
the worse cases installed here.


Worth investigation, not by you, but those that loathe systemd should 
have a look and see if they could fix some.



For your needs probably just pivoting a symlink should work almost fine,
as long your stay sysvinit compatible, yet doing that as early init or
as post kill-all should work better even in your case.


Well, you're transforming a simple idea with potentially relatively
wide audience into a horror story with a single user.


Hopefully not =) I just stated what's the problem and the possible 
solutions. As said from start I want the whole thing to be an opt-in and 
to cause the least amount of disruption on current setups.


Patching sysvinit and bb-init to accept a -c filename would make the 
whole thing much simpler if we pick a wrapper solution for my most 
complex case.


lu

Re: [gentoo-dev] eselect init

[J. Roeleveld]

On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
 On Sat, 25 May 2013 21:09:47 +0200
 J. Roeleveld jo...@antarean.org wrote:

 How will the stop/start part of services/init-scripts/... be done?

 Not sure what you mean here; if you keep init function the same as the
 init you boot with, this should continue to work.

As an example. Lets say I want to test a new init-system. To do this, I
follow the (still to be written) guide on eselect init and boot into
new-and-shiny-init-system.

I am still used to stopping/starting services using /etc/init.d/service
start/stop
And using the rc command to add/remove services from the runlevel(s).

If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't
been started by any means yet. What will happen?
I would assume that openrc will try to start xyz?
This is, I believe, something that could cause issues as dependencies
might also try to start and I then have a service running not managed by
the new-and-shiny-init-system that I was testing.

 I am assuming that should be for the user to keep in mind, but will
 it be possible to add something that will make init.d-scripts not
 work when systemd is running and unit-files not work when systemd is
 not running?

 They currently just bail out with bogus errors as far as I am aware.

  # /etc/init.d/ntpd start
 ntpd | * WARNING: ntpd is already starting
  # /etc/init.d/ntpd stop
 ntpd | * ERROR: ntpd stopped by something else

See above, what about if ntpd wasn't running yet?

  hooks on reboot are still needed for more complex ones.
 
  Which complex cases would these hooks be needed on?

 I think one of these would be the stopping/starting of services (see
 above)

 No, if you keep the init system the same as the one you boot with there
 should be no problems.

See above, what about trying to start services using the method of the
not-running init?

 [[ Below is my ONLY remark on that, please feel free to mentally
 paste it as a response any email trying to explain why it's important
 to reduce the boottime ]]

 My intention was not to advocate optimizing boot times;

I know, that bit was meant generic, not just as a reply to you.

 as a kernel
 maintainer / developer I need to test new releases, run git bisects, do
 Nouveau reclocking work. I really need this, the average person that
 keeps his PC running, not so much; I care for it because I can't wait 2
 minutes, not because I think it's shiny to have such a short boot...

 PS: I'm also a mobile laptop user that no longer has a battery. :/

I believe you can still use hibernate there? :)

--
Joost

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sat, 25 May 2013 21:55:20 +0200
Tom Wijsman tom...@gentoo.org wrote:

 On Sat, 25 May 2013 21:09:47 +0200
 J. Roeleveld jo...@antarean.org wrote:
 
  +1 for wrapper, from my understanding, symlinks for init-systems
  can't be altered on a running system without risking strange
  behaviour.
 
 Exactly...
 
  # shutdown -h now
 
 The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41
 2013): Excess arguments.

I don't know what is the state of your system when testing this but on
my system /sbin/telinit is a symlink to /sbin/init. So replacing
the latter also replaces telinit with something unexpected.

Of course, the solution is to make telinit point to the real sysvinit
executable. Not sure how well it will reboot then, however. It may be
necessary to also change 'halt' to use 'telinit' if it uses 'init'
directly.

  I am assuming that should be for the user to keep in mind, but will
  it be possible to add something that will make init.d-scripts not
  work when systemd is running and unit-files not work when systemd is
  not running?
 
 They currently just bail out with bogus errors as far as I am aware.
 
  # /etc/init.d/ntpd start
 ntpd | * WARNING: ntpd is already starting
  # /etc/init.d/ntpd stop
 ntpd | * ERROR: ntpd stopped by something else

I think we fixed this already... well, not exactly this because openrc
used to try to actually start stuff. I would consider this a regression
since it had explanatory error messages.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 14:59:28 +0200
J. Roeleveld jo...@antarean.org wrote:

 As an example. Lets say I want to test a new init-system. [SNIP] 
 If I then, accidentally, type /etc/init.d/xyz start when xyz
 hasn't been started by any means yet. What will happen?
 I would assume that openrc will try to start xyz?

As I said before:

  They currently just bail out with bogus errors as far as I am aware.
 
   # /etc/init.d/ntpd start
  ntpd | * WARNING: ntpd is already starting
   # /etc/init.d/ntpd stop
  ntpd | * ERROR: ntpd stopped by something else
 
 See above, what about if ntpd wasn't running yet?

ntpd isn't running on my system and wasn't when I did that.

  No, if you keep the init system the same as the one you boot with
  there should be no problems.
 
 See above, what about trying to start services using the method of the
 not-running init?

The same, feel free to emerge systemd and try to start a service; I
expect this to bail out since its dependencies aren't started, for its
dependencies to start the init system itself should be in use.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 15:15:26 +0200
Michał Górny mgo...@gentoo.org wrote:

 Cc: tom...@gentoo.org

Please don't CC me, this causes duplicate mails; one of both does not
include reply-to. Nobody else that has responded to me did this before.

Unless you can give me an awesome procmail rule to process these... :)

 I don't know what is the state of your system when testing this but on
 my system /sbin/telinit is a symlink to /sbin/init. So replacing
 the latter also replaces telinit with something unexpected.

I did something like `mv /sbin/init{,.bak} ; mv systemd /sbin/init`

 Of course, the solution is to make telinit point to the real sysvinit
 executable. Not sure how well it will reboot then, however. It may be
 necessary to also change 'halt' to use 'telinit' if it uses 'init'
 directly.

Currently I use `systemctl reboot` and `systemctl poweroff`, I
actually have no idea how to make telinit work again with systemd.

   # /etc/init.d/ntpd start
  ntpd | * WARNING: ntpd is already starting
   # /etc/init.d/ntpd stop
  ntpd | * ERROR: ntpd stopped by something else
 
 I think we fixed this already... well, not exactly this because openrc
 used to try to actually start stuff. I would consider this a
 regression since it had explanatory error messages.

The stop error is reasonable I think, the start error is indeed odd.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 25/05/13 03:08 PM, Matthew Thode wrote:
 On 05/25/13 05:25, Peter Stuge wrote:
 Luca Barbato wrote:
 - init gets effectively switched only at boot/reboot
 
 Please not on reboot, because an unclean shutdown shouldn't leave
 the system in limbo.
 
 On boot could work, except that it does add more steps (= more 
 fragility) to the boot process, which I think everyone wants to 
 avoid.
 
 I would actually expect the change to take effect immediately.
 
 
 //Peter
 
 the final action before / is remouted ro at shutdown would make
 sense to me.  It's either that or first action at boot.
 

First action at boot, without an initramfs, is too late isn't it?  The
kernel has already launched init at this point.  Also, relying on
something at shutdown is going to be problematic too -- openrc and
systemd (and whatever others) all need the functionality to do this
built into their scripts, and cases of dirty shutdowns are not going
to be handled well.

The only way I can think of that this is going to work, every time,
reliably, is if it was done within an initramfs and therefore prior to
the start of actual init (ie, initramfs would read a config file to
determine what init-selector to run, calls the init-selector actions,
and then exec's that init -- that config file could be
eselect-controlled or just edited)

And that brings back in the whole initramfs-required flamewar


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGiGIMACgkQ2ugaI38ACPBw+gD6A6F5DF6fTFYibbpBjueg1rw1
SL/zUYRomTXDrfhqbDUA/3YxUCAeXrX8dDAlQKbomWnVCG9gKrZObOF5lFo/MXZs
=GXEk
-END PGP SIGNATURE-

Re: [gentoo-dev] eselect init

[Rich Freeman]

On Sun, May 26, 2013 at 10:07 AM, Tom Wijsman tom...@gentoo.org wrote:
 On Sun, 26 May 2013 15:15:26 +0200
 Michał Górny mgo...@gentoo.org wrote:

 Cc: tom...@gentoo.org

 Please don't CC me, this causes duplicate mails; one of both does not
 include reply-to. Nobody else that has responded to me did this before.

 Unless you can give me an awesome procmail rule to process these... :)


:0 Wh: msgid.lock
| formail -D 8192 msgid.cache

:0 a:
.duplicates/new

(or /dev/null as you prefer)

I'm sure it isn't perfect, but I've been running it for years.
Between lists and aliases I'd be buried in dups otherwise.

Apologies for the OT, but I figured this was useful, and you did ask...

Rich

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 1:58 PM, Tom Wijsman wrote:

On Sun, 26 May 2013 12:57:42 +0200
Michał Górny mgo...@gentoo.org wrote:


Switch inittab? Now you added really dangerous behavior to the wrapper
code. I can hardly even express this in words.


It doesn't need to be in the wrapper, inittab is something read at boot
only as far as I am aware and therefore eselect can do it.


Apparently it is read when you switch runlevel as well.

lu

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26/05/13 07:40 AM, Luca Barbato wrote:
 On 5/26/13 12:57 PM, Michał Górny wrote:
 You are telling me that a wrapper, a thing that gets executed
 *every* boot needs to do some random magic to know which init
 system was in use and which one is supposed to be in use, and
 then conditionally move around configuration files necessary for
 it to run. This is just *INSANE*.
 
 I like to think it normal and the wrapper doesn't need to run every
 time but only when a switch had been requested. And only if you
 prefer doing the switch at boot time instead than at shutdown.
 

The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)

I don't know (outside of a script in the initramfs) how this would
otherwise be handled to cover all cases.  I am curious though, if you
see a way to do this otherwise, what the implementation would look like?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGiIxAACgkQ2ugaI38ACPDrbAD/exZAI4utNuOBAMzdkeYj8JgB
lmeOg+G892g4yYMa6cIBALEQMH3bliQ0hF3HEtJezdbzG4/XkaEdGIjM+gscxF79
=9J3a
-END PGP SIGNATURE-

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26/05/13 08:59 AM, J. Roeleveld wrote:
 On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
 On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld
 jo...@antarean.org wrote:
 
 How will the stop/start part of services/init-scripts/... be
 done?
 
 Not sure what you mean here; if you keep init function the same
 as the init you boot with, this should continue to work.
 
 As an example. Lets say I want to test a new init-system. To do
 this, I follow the (still to be written) guide on eselect init
 and boot into new-and-shiny-init-system.
 
 I am still used to stopping/starting services using
 /etc/init.d/service start/stop And using the rc command to
 add/remove services from the runlevel(s).
 
 If I then, accidentally, type /etc/init.d/xyz start when xyz
 hasn't been started by any means yet. What will happen? I would
 assume that openrc will try to start xyz? This is, I believe,
 something that could cause issues as dependencies might also try to
 start and I then have a service running not managed by the
 new-and-shiny-init-system that I was testing.

Point #1 - openrc isn't init -- 'eselect init' or w/e is not
necessarily going to be the same as 'eselect rc-system'.  It's
unlikely that you'll want to use another rc system if using systemd
for your init, but that doesn't mean you can't.

Point #2 - yes, this can be an issue and I believe it's already being
worked on separately; WilliamH has mentioned issues like this more
than once on irc, at least, although I don't know if he's implemented
any solution(s).

This bit should go into a separate thread or bug, and not be
considered part of the overall 'eselect init' solution imo.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGiIiQACgkQ2ugaI38ACPA7dwD/Y6IJo+/j2Ho4p1bM8mGMt7E8
ZglL7SvNS7g/90K6n1gA/37F0u5v2gzIoSTVi6uEmyhcPMW/2I2vr+YRv0rALO8S
=PuVY
-END PGP SIGNATURE-

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sun, 26 May 2013 16:52:27 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 On 5/26/13 1:58 PM, Tom Wijsman wrote:
  On Sun, 26 May 2013 12:57:42 +0200
  Michał Górny mgo...@gentoo.org wrote:
 
   Switch inittab? Now you added really dangerous behavior to the
   wrapper code. I can hardly even express this in words.
 
  It doesn't need to be in the wrapper, inittab is something read at
  boot only as far as I am aware and therefore eselect can do it.
 
 Apparently it is read when you switch runlevel as well.

Ouch, that indeed makes it impossible for eselect to do this and makes
the wrapper more complex; unless there is a sane way to on reboot, but
then we would be implementing this in too many places. I think some of
the other suggestions made here also don't take this into account.

Thanks for mentioning.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[William Hubbs]

On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
 Openrc is small, but the wrapper really needs to know which is which and 
 worst case switch inittab.

Please explain why this wrapper would need to switch inittab. Inittab is
only used by sysvinit and has no uses in any other init system.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[William Hubbs]

On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
 On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
  Openrc is small, but the wrapper really needs to know which is which and 
  worst case switch inittab.
 
 Please explain why this wrapper would need to switch inittab. Inittab is
 only used by sysvinit and has no uses in any other init system.

Ok, sorry, I was wrong in my previous msg, now I see that bb-init has
its own inittab with a different format.

How about patching bb-init so that it can handle a sysvinit inittab?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[Michał Górny]

On Sun, 26 May 2013 11:48:30 -0500
William Hubbs willi...@gentoo.org wrote:

 On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
  On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
   Openrc is small, but the wrapper really needs to know which is which and 
   worst case switch inittab.
  
  Please explain why this wrapper would need to switch inittab. Inittab is
  only used by sysvinit and has no uses in any other init system.
 
 Ok, sorry, I was wrong in my previous msg, now I see that bb-init has
 its own inittab with a different format.
 
 How about patching bb-init so that it can handle a sysvinit inittab?

Er, isn't that too far to diverge from upstream? If we're to patch
something, I'd rather patch it to use a different path.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[William Hubbs]

On Sun, May 26, 2013 at 06:55:45PM +0200, Michał Górny wrote:
 On Sun, 26 May 2013 11:48:30 -0500
 William Hubbs willi...@gentoo.org wrote:
 
  On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
   On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
Openrc is small, but the wrapper really needs to know which is which 
and 
worst case switch inittab.
   
   Please explain why this wrapper would need to switch inittab. Inittab is
   only used by sysvinit and has no uses in any other init system.
  
  Ok, sorry, I was wrong in my previous msg, now I see that bb-init has
  its own inittab with a different format.
  
  How about patching bb-init so that it can handle a sysvinit inittab?
 
 Er, isn't that too far to diverge from upstream? If we're to patch
 something, I'd rather patch it to use a different path.

From what I just read, the difference is that busybox init ignores the
runlevels specified in sysvinit inittab.

I guess it isn't an error for the runlevels to be there, it just doesn't
do anything with them.

Luca,

If that's the only difference, do we really need to modify the inittab
at all?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/27/13 12:58 AM, William Hubbs wrote:

From what I just read, the difference is that busybox init ignores the
runlevels specified in sysvinit inittab.


Nope, it interprets the numbers in a different way.


If that's the only difference, do we really need to modify the inittab
at all?


Yes, I tested it first and got the whole system unworkable, one single 
mode later I baked something to get at least the minimal functionality, 
supporting our xdm script properly required some more effort I hadn't 
time to pour that day.


lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 4:13 PM, Ian Stakenvicius wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 25/05/13 03:08 PM, Matthew Thode wrote:

On 05/25/13 05:25, Peter Stuge wrote:

Luca Barbato wrote:

- init gets effectively switched only at boot/reboot


Please not on reboot, because an unclean shutdown shouldn't leave
the system in limbo.

On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.

I would actually expect the change to take effect immediately.


//Peter


the final action before / is remouted ro at shutdown would make
sense to me.  It's either that or first action at boot.



First action at boot, without an initramfs, is too late isn't it?


bootchart2 shows that is quite possible and working fine for it =)

The current mode to switch init manually for my use-case is to drop to 
single user, do your stuff, reboot or reload init if the init or the 
operating system supports it.


Drop to single user is quite the same as rebooting anyway.

lu

Re: [gentoo-dev] eselect init

[Peter Stuge]

Luca Barbato wrote:
 - init gets effectively switched only at boot/reboot

Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.

On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.

I would actually expect the change to take effect immediately.


//Peter

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
 Hi, since the whole discussion got somehow sidetracked on where and if
 to install for everybody the rc system specific files for everybody
 (that should be an implementation detail for the specific dohelper
 IMHO), I'm back to the other part of it: switching the actual init
 implementation.
 
 # WHY (not just edit your bootloader)
 
 Since efi at least some people started to put in the kernel the bootargs
 and we have at least few new options brewing for init, some are
 small impact (bootchar, bb-init-openrc and runit-openrc) some are more
 invasive (runit and systemd).

I use e4rat and, for that, I need to add 
init=/sbin/e4rat-preload

to my grub.conf, I guess this wouldn't change with this, no? :/

Thanks for the info!

Re: [gentoo-dev] eselect init

[Sergei Trofimovich]

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:

 Hi, since the whole discussion got somehow sidetracked on where and if
 to install for everybody the rc system specific files for everybody
 (that should be an implementation detail for the specific dohelper
 IMHO), I'm back to the other part of it: switching the actual init
 implementation.
 
 # WHY (not just edit your bootloader)
 
 Since efi at least some people started to put in the kernel the bootargs
 and we have at least few new options brewing for init, some are
 small impact (bootchar, bb-init-openrc and runit-openrc) some are more
 invasive (runit and systemd).
 
 In those setup changing bootargs requires a kernel rebuild and some
 effort, while the eselect approach stays completely transparent.
 
 For some switch we might not have just to change the init binary bit
 also to do some other changes (e.g. use a different format for inittab)

If you can't change options at boot time it's very simple to get
unbootable system. Just curious, who does such systems and
how root filesystem (+ it's mount options) is expected to be
found there?

I guess EFI allows you to set bootargs via EFI UI.

I'd go for init=/sbin/gentoo-init and make all the messy stuff there.
Otherwise by breaking /sbin/init it would be hard to find proper
name of, say, SYSVs /sbin/init. How would you call it?

 # KEYPOINTS
 
 - /sbin/init (or whatever linux currently calls by default with top
 priority) should be either a symlink to the actual implementation or a
 wrapper such as our gcc one. I like better the latter since it is
 overall safer. The former might or might work since linux has some
 fallback capabilities but hadn't been tested.
 
 - init gets effectively switched only at boot/reboot, eselect init must
 keep track of the current active init and make sure the current init
 configuration is used till the system reboots, if we use the wrapper
 approach, it would pick up what's the new init at boot and that would be
 enough for simple cases, hooks on reboot are still needed for more
 complex ones.
 
 - we could try to not have the changes to the current init systems
 ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init)
 
 # FOCUS
 
 My interest is mostly if not all on bb-init-openrc and slightly on
 runit-openrc.
 
 There are enough people involved in systemd and since I still consider
 it a dangerously frail implementation of a bad idea is better if I do
 not touch it at all.
 
 My system with stock openrc gets from linux start to graphical login in
 less than 6s and I'm not using Gnome so I do not have any reason to use
 it beside comparing.
 
 lu
 
 


-- 

  Sergei


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge pe...@stuge.se wrote:

 I would actually expect the change to take effect immediately.

Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is that when you boot with an init system you
must shutdown with that same init system, you can't just start one init
system and expect the other init system to cleanly shut down its
services. Therefore implementing this would either be unclean or way to
complex. 

From all the methods discussed doing it on boot sounds the most sane.

 On boot could work, except that it does add more steps (= more
 fragility) to the boot process, which I think everyone wants to avoid.

If it is implemented properly, it really isn't that fragile as you
would think; it doesn't take much input, so there is barely any
implementation and bug fixing needed and it will work everywhere.

Users that manage to break this will often know how to fix, unless we
messed up from the Portage tree; but well, this mostly boils down to a
proper news item and documentation _before_ bringing this out such that
users are at least aware of this crucial boot process change.

Anyhow, users need to be aware anyway for when they ever decide to try
or switch another init system in the future.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sat, 25 May 2013 13:13:36 +0200
Pacho Ramos pa...@gentoo.org wrote:

 I use e4rat and, for that, I need to add 
 init=/sbin/e4rat-preload
 
 to my grub.conf, I guess this wouldn't change with this, no? :/
 
 Thanks for the info!

That instead of the default will first load e4rat-preload and only
after that the init symlink / wrapper will be called. 

So, the changes being discussed here will not prevent e4rat-preload
from running, but rather change what would happen after e4rat-preload
kicks off init. It is a transparent change and should not affect
e4rat-preload functionality in a bad way.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] eselect init

[hasufell]

Isn't eselect for cases where I might want to reconfigure something or
add configuration values such as for bash-completion, do testing with
java-vm or python implementations during development, switch opengl
implementation depending on the graphics driver loaded and whatnot.

I don't see any of this applying to init system, nor do I see a reason
to randomly switch between those. It's rather something to configure
during installation, so I'd rather expect proper documentation.

But I am not opposing, I just find it weird.

Re: [gentoo-dev] eselect init

[Tom Wijsman]

On Sat, 25 May 2013 14:29:12 +0300
Sergei Trofimovich sly...@gentoo.org wrote:

 If you can't change options at boot time it's very simple to get
 unbootable system.

https://bugs.gentoo.org/show_bug.cgi?id=465236#c34

In above Bug #465236 at Comment #34 the suggestion has been made to
maybe call the wrapper /sbin/einit and leave /sbin/init at a sane
default. That way the user should still be able to boot the Gentoo
default as long as it does not end up being removed from the system.

In other words, changing init=/sbin/einit back to init/sbin/init fixes
things; I don't think it's asked too much to add init=/sbin/einit in
the bootloader or kernel in the alternative init systems documentation.

 Just curious, who does such systems and how root filesystem (+ it's
 mount options) is expected to be found there?

I don't see how this is a problem; the kernel loads what you have
set as init and after that you have root filesystem access, possibly
read only at this point but you don't have to find the root fs here.

 I guess EFI allows you to set bootargs via EFI UI.

Not so sure about this, but most people end up hardcoding it in the
kernel; you can do this by setting CONFIG_CMDLINE.

 I'd go for init=/sbin/gentoo-init and make all the messy stuff there.
 Otherwise by breaking /sbin/init it would be hard to find proper
 name of, say, SYSVs /sbin/init. How would you call it?

Yeah, this is what the /sbin/einit suggestion above tries to resolve.

We shouldn't have our users guess at names here, all they should
know is to add einit if they wish to be able to switch and that
removing it will load the default init system present on Gentoo...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature