rfc: virtual/init for init process

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

rfc: virtual/init for init process

William Hubbs
Hi all,

In the past, openrc has had a dependency on sysvvinit because it called
killall5. Since it doesn't do that any more, I have been asked to remove
the dependency [1]. Another advantage of doing this is that people will
be able to build profiles without an init package, for containers for
example.

To do this, I need to add virtual/init for packages that have an init
process. then add virtual/init to profiles/base/packages.

Please proofread virtual/init as attached before I add it to the tree.

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=599468



init-0.ebuild (705 bytes) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Jason Zaman-2
On Wed, Apr 25, 2018 at 02:20:29PM -0500, William Hubbs wrote:

> Hi all,
>
> In the past, openrc has had a dependency on sysvvinit because it called
> killall5. Since it doesn't do that any more, I have been asked to remove
> the dependency [1]. Another advantage of doing this is that people will
> be able to build profiles without an init package, for containers for
> example.
>
> To do this, I need to add virtual/init for packages that have an init
> process. then add virtual/init to profiles/base/packages.
>
> Please proofread virtual/init as attached before I add it to the tree.
>
> Thanks,
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=599468
>
>

> # Copyright 1999-2018 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> EAPI=6
>
> DESCRIPTION="virtual for process 1"
>
> SLOT="0"
> KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt"
> IUSE=""

Dont you need:
IUSE="prefix selinux kernel_linux kernel_FreeBSD"

> RDEPEND="
> !prefix? (
> kernel_linux? (
> || (
> >=sys-apps/sysvinit-2.86-r6[selinux?]
> sys-apps/systemd

For consistency with the one above, this should probably be
sys-apps/systemd[selinux?]

-- Jason

> )
> selinux? (
> >=sec-policy/selinux-base-policy-2.20170204-r4
> )
> )
> kernel_FreeBSD? (
> sys-freebsd/freebsd-sbin
> )
> )"




Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Ulrich Mueller-2
>>>>> On Thu, 26 Apr 2018, Jason Zaman wrote:

>> IUSE=""

> Dont you need:
> IUSE="prefix selinux kernel_linux kernel_FreeBSD"

prefix and KERNEL are injected from profiles/base/make.defaults, so no
need to have them in IUSE.

selinux might be needed indeed.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Michał Górny-5
W dniu czw, 26.04.2018 o godzinie 16∶46 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Thu, 26 Apr 2018, Jason Zaman wrote:
> > > IUSE=""
> > Dont you need:
> > IUSE="prefix selinux kernel_linux kernel_FreeBSD"
>
> prefix and KERNEL are injected from profiles/base/make.defaults, so no
> need to have them in IUSE.

Still, explicit is better than implicit, especially when there's no harm
from being explicit.

>
> selinux might be needed indeed.
>
> Ulrich

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Mike Gilbert-2
In reply to this post by William Hubbs
On Wed, Apr 25, 2018 at 3:20 PM, William Hubbs <[hidden email]> wrote:

> Hi all,
>
> In the past, openrc has had a dependency on sysvvinit because it called
> killall5. Since it doesn't do that any more, I have been asked to remove
> the dependency [1]. Another advantage of doing this is that people will
> be able to build profiles without an init package, for containers for
> example.
>
> To do this, I need to add virtual/init for packages that have an init
> process.        then add virtual/init to profiles/base/packages.
>
> Please proofread virtual/init as attached before I add it to the tree.

If this is really intended to pull in any program that could feasibly
be used as PID 1, there are probably multiple providers missing. A
couple off the top of my head:

sys-apps/busybox
sys-apps/openrc (openrc-init)

If the virtual is meant to represent something else (as I suspect it
is), please elaborate.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

William Hubbs
Here is the latest version of this virtual based on feedback from the
list so far.

I have added some providers and cleaned up IUSE.

Thanks,

William


init-0.ebuild (825 bytes) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

William Hubbs
After some discussion on IRC, I need to drop busybox from this virtual
because it is in packages already. OpenRC needs to be dropped because
for now we do not have a way to make sure both openrc and sysvinit get
installed in stage 3 if openrc is listed both in virtual/init and
virtual/service-manager.

William

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Zac Medico-2
On 04/26/2018 01:08 PM, William Hubbs wrote:
> After some discussion on IRC, I need to drop busybox from this virtual
> because it is in packages already. OpenRC needs to be dropped because
> for now we do not have a way to make sure both openrc and sysvinit get
> installed in stage 3 if openrc is listed both in virtual/init and
> virtual/service-manager.

I predict that a non-zero number of users that have sys-apps/s6 or
sys-process/runit will accidentally/blindly remove sys-apps/sysvinit via
emerge --depclean, resulting in an unbootable system. Just say-in.
--
Thanks,
Zac


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Kent Fredric-2
On Thu, 26 Apr 2018 13:35:15 -0700
Zac Medico <[hidden email]> wrote:

> emerge --depclean, resulting in an unbootable system. Just say-in.

And depclean being very verbose doesn't do many favours here either.

( I regularly do >500 package depcleans and spotting things that aren't meant to be
 culled amongst that list is a bit of a challenge )

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Zac Medico-2
On 04/26/2018 11:34 PM, Kent Fredric wrote:
> On Thu, 26 Apr 2018 13:35:15 -0700
> Zac Medico <[hidden email]> wrote:
>
>> emerge --depclean, resulting in an unbootable system. Just say-in.
>
> And depclean being very verbose doesn't do many favours here either.
>
> ( I regularly do >500 package depcleans and spotting things that aren't meant to be
>  culled amongst that list is a bit of a challenge )>

At least for system packages, it will show a warning like the one shown
here:

   https://bugs.gentoo.org/642484#c0

Hopefully that message helps those that are paying enough attention.
What can we do for those that overlook the warning message, other than
give them some rescue instructions for making their system boot again?
--
Thanks,
Zac


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Pacho Ramos
El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió:

> On 04/26/2018 11:34 PM, Kent Fredric wrote:
> > On Thu, 26 Apr 2018 13:35:15 -0700
> > Zac Medico <[hidden email]> wrote:
> >
> > > emerge --depclean, resulting in an unbootable system. Just say-in.
> >
> > And depclean being very verbose doesn't do many favours here either.
> >
> > ( I regularly do >500 package depcleans and spotting things that aren't
> > meant to be
> >  culled amongst that list is a bit of a challenge )>
>
> At least for system packages, it will show a warning like the one shown
> here:
>
>    https://bugs.gentoo.org/642484#c0
>
> Hopefully that message helps those that are paying enough attention.
> What can we do for those that overlook the warning message, other than
> give them some rescue instructions for making their system boot again?

Have you think in changing a bit the behavior of depclean to *not* depclean
system packages and ask administrator to do something like "emerge -a --depclean
--force" to force the depclean of that packages?

That could help to prevent that mistakes I think

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

William Hubbs
In reply to this post by Zac Medico-2
On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote:

> On 04/26/2018 11:34 PM, Kent Fredric wrote:
> > On Thu, 26 Apr 2018 13:35:15 -0700
> > Zac Medico <[hidden email]> wrote:
> >
> >> emerge --depclean, resulting in an unbootable system. Just say-in.
> >
> > And depclean being very verbose doesn't do many favours here either.
> >
> > ( I regularly do >500 package depcleans and spotting things that aren't meant to be
> >  culled amongst that list is a bit of a challenge )>
>
> At least for system packages, it will show a warning like the one shown
> here:
>
>    https://bugs.gentoo.org/642484#c0
>
> Hopefully that message helps those that are paying enough attention.
> What can we do for those that overlook the warning message, other than
> give them some rescue instructions for making their system boot again?
Another option suggested to me was to add a use flag to OpenRC that
pulls in a dependency on virtual/init instead of adding virtual/init to
@system. The suggestion originally was to add it to rdepend, but that
doesn't feel right to me since openrc really doesn't have a runtime
dependency on init, so I'm thinking something like this:

IUSE="... +separate-init"

PDEPEND="
...
separate-init? ( virtual/init )"

Thoughts?

William


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Zac Medico-2
On 04/27/2018 08:45 AM, William Hubbs wrote:

> On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote:
>> On 04/26/2018 11:34 PM, Kent Fredric wrote:
>>> On Thu, 26 Apr 2018 13:35:15 -0700
>>> Zac Medico <[hidden email]> wrote:
>>>
>>>> emerge --depclean, resulting in an unbootable system. Just say-in.
>>>
>>> And depclean being very verbose doesn't do many favours here either.
>>>
>>> ( I regularly do >500 package depcleans and spotting things that aren't meant to be
>>>  culled amongst that list is a bit of a challenge )>
>>
>> At least for system packages, it will show a warning like the one shown
>> here:
>>
>>    https://bugs.gentoo.org/642484#c0
>>
>> Hopefully that message helps those that are paying enough attention.
>> What can we do for those that overlook the warning message, other than
>> give them some rescue instructions for making their system boot again?
>
> Another option suggested to me was to add a use flag to OpenRC that
> pulls in a dependency on virtual/init instead of adding virtual/init to
> @system. The suggestion originally was to add it to rdepend, but that
> doesn't feel right to me since openrc really doesn't have a runtime
> dependency on init, so I'm thinking something like this:
>
> IUSE="... +separate-init"
>
> PDEPEND="
> ...
> separate-init? ( virtual/init )"
>
> Thoughts?
Yes, I like this idea.
--
Thanks,
Zac


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Zac Medico-2
In reply to this post by Pacho Ramos
On 04/27/2018 08:43 AM, Pacho Ramos wrote:

> El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió:
>> On 04/26/2018 11:34 PM, Kent Fredric wrote:
>>> On Thu, 26 Apr 2018 13:35:15 -0700
>>> Zac Medico <[hidden email]> wrote:
>>>
>>>> emerge --depclean, resulting in an unbootable system. Just say-in.
>>>
>>> And depclean being very verbose doesn't do many favours here either.
>>>
>>> ( I regularly do >500 package depcleans and spotting things that aren't
>>> meant to be
>>>  culled amongst that list is a bit of a challenge )>
>>
>> At least for system packages, it will show a warning like the one shown
>> here:
>>
>>    https://bugs.gentoo.org/642484#c0
>>
>> Hopefully that message helps those that are paying enough attention.
>> What can we do for those that overlook the warning message, other than
>> give them some rescue instructions for making their system boot again?
>
> Have you think in changing a bit the behavior of depclean to *not* depclean
> system packages and ask administrator to do something like "emerge -a --depclean
> --force" to force the depclean of that packages?
>
> That could help to prevent that mistakes I think
I don't want this system packages warning to do anything other that
change the display, since it's really based on heuristics. The sysvinit
package wouldn't be removed if it was the only provider of virtual/init,
and it only triggers the warning because it's the preferred provider.
--
Thanks,
Zac


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Mike Gilbert-2
In reply to this post by William Hubbs
On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs <[hidden email]> wrote:

> On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote:
>> On 04/26/2018 11:34 PM, Kent Fredric wrote:
>> > On Thu, 26 Apr 2018 13:35:15 -0700
>> > Zac Medico <[hidden email]> wrote:
>> >
>> >> emerge --depclean, resulting in an unbootable system. Just say-in.
>> >
>> > And depclean being very verbose doesn't do many favours here either.
>> >
>> > ( I regularly do >500 package depcleans and spotting things that aren't meant to be
>> >  culled amongst that list is a bit of a challenge )>
>>
>> At least for system packages, it will show a warning like the one shown
>> here:
>>
>>    https://bugs.gentoo.org/642484#c0
>>
>> Hopefully that message helps those that are paying enough attention.
>> What can we do for those that overlook the warning message, other than
>> give them some rescue instructions for making their system boot again?
>
> Another option suggested to me was to add a use flag to OpenRC that
> pulls in a dependency on virtual/init instead of adding virtual/init to
> @system. The suggestion originally was to add it to rdepend, but that
> doesn't feel right to me since openrc really doesn't have a runtime
> dependency on init, so I'm thinking something like this:
>
> IUSE="... +separate-init"
>
> PDEPEND="
> ...
> separate-init? ( virtual/init )"
>
> Thoughts?

RDEPEND and PDEPEND have essentially the same meaning when there are
no cycles in the dependency graph. The devmanual suggests that PDEPEND
should only be used to avoid cyclic dependencies.

I don't see any reason to prefer PDEPEND over RDEPEND here, and I
don't understand why that would "feel" better. It effectively gets
treated as a runtime dependency either way.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

William Hubbs
On Fri, Apr 27, 2018 at 12:28:43PM -0400, Mike Gilbert wrote:

> On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs <[hidden email]> wrote:
> > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote:
> >> On 04/26/2018 11:34 PM, Kent Fredric wrote:
> >> > On Thu, 26 Apr 2018 13:35:15 -0700
> >> > Zac Medico <[hidden email]> wrote:
> >> >
> >> >> emerge --depclean, resulting in an unbootable system. Just say-in.
> >> >
> >> > And depclean being very verbose doesn't do many favours here either.
> >> >
> >> > ( I regularly do >500 package depcleans and spotting things that aren't meant to be
> >> >  culled amongst that list is a bit of a challenge )>
> >>
> >> At least for system packages, it will show a warning like the one shown
> >> here:
> >>
> >>    https://bugs.gentoo.org/642484#c0
> >>
> >> Hopefully that message helps those that are paying enough attention.
> >> What can we do for those that overlook the warning message, other than
> >> give them some rescue instructions for making their system boot again?
> >
> > Another option suggested to me was to add a use flag to OpenRC that
> > pulls in a dependency on virtual/init instead of adding virtual/init to
> > @system. The suggestion originally was to add it to rdepend, but that
> > doesn't feel right to me since openrc really doesn't have a runtime
> > dependency on init, so I'm thinking something like this:
> >
> > IUSE="... +separate-init"
> >
> > PDEPEND="
> > ...
> > separate-init? ( virtual/init )"
> >
> > Thoughts?
>
> RDEPEND and PDEPEND have essentially the same meaning when there are
> no cycles in the dependency graph. The devmanual suggests that PDEPEND
> should only be used to avoid cyclic dependencies.
>
> I don't see any reason to prefer PDEPEND over RDEPEND here, and I
> don't understand why that would "feel" better. It effectively gets
> treated as a runtime dependency either way.
The goal of this is to find a way to accurately reflect the relationship
between openrc and sysvinit in our ebuilds.

The relationship between openrc and sysvinit is best described as a
configurable reverse runtime dependency which we enable by default --
sysvinit uses openrc to bring up the system, but openrc itself does not
have a hard dependency on any init provider.
It did in the past, because it called killall5, which is part of
sysvinit, but that has been changed.

So, the whole relationship is backward in our ebuilds. That, combined
with our distro-wide ban on using use flags for optional runtime
dependencies (also in the devmanual) is why I suggested this.

William


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Mike Gilbert-2
On Fri, Apr 27, 2018 at 1:28 PM, William Hubbs <[hidden email]> wrote:

> On Fri, Apr 27, 2018 at 12:28:43PM -0400, Mike Gilbert wrote:
>> On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs <[hidden email]> wrote:
>> > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote:
>> >> On 04/26/2018 11:34 PM, Kent Fredric wrote:
>> >> > On Thu, 26 Apr 2018 13:35:15 -0700
>> >> > Zac Medico <[hidden email]> wrote:
>> >> >
>> >> >> emerge --depclean, resulting in an unbootable system. Just say-in.
>> >> >
>> >> > And depclean being very verbose doesn't do many favours here either.
>> >> >
>> >> > ( I regularly do >500 package depcleans and spotting things that aren't meant to be
>> >> >  culled amongst that list is a bit of a challenge )>
>> >>
>> >> At least for system packages, it will show a warning like the one shown
>> >> here:
>> >>
>> >>    https://bugs.gentoo.org/642484#c0
>> >>
>> >> Hopefully that message helps those that are paying enough attention.
>> >> What can we do for those that overlook the warning message, other than
>> >> give them some rescue instructions for making their system boot again?
>> >
>> > Another option suggested to me was to add a use flag to OpenRC that
>> > pulls in a dependency on virtual/init instead of adding virtual/init to
>> > @system. The suggestion originally was to add it to rdepend, but that
>> > doesn't feel right to me since openrc really doesn't have a runtime
>> > dependency on init, so I'm thinking something like this:
>> >
>> > IUSE="... +separate-init"
>> >
>> > PDEPEND="
>> > ...
>> > separate-init? ( virtual/init )"
>> >
>> > Thoughts?
>>
>> RDEPEND and PDEPEND have essentially the same meaning when there are
>> no cycles in the dependency graph. The devmanual suggests that PDEPEND
>> should only be used to avoid cyclic dependencies.
>>
>> I don't see any reason to prefer PDEPEND over RDEPEND here, and I
>> don't understand why that would "feel" better. It effectively gets
>> treated as a runtime dependency either way.
>
> The goal of this is to find a way to accurately reflect the relationship
> between openrc and sysvinit in our ebuilds.
>
> The relationship between openrc and sysvinit is best described as a
> configurable reverse runtime dependency which we enable by default --
> sysvinit uses openrc to bring up the system, but openrc itself does not
> have a hard dependency on any init provider.
> It did in the past, because it called killall5, which is part of
> sysvinit, but that has been changed.
>
> So, the whole relationship is backward in our ebuilds. That, combined
> with our distro-wide ban on using use flags for optional runtime
> dependencies (also in the devmanual) is why I suggested this.

I have no objection to the USE flag idea. Just put the dependency in
RDEPEND, not PDEPEND. There is no depgraph cycle to be avoided here.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Zac Medico-2
In reply to this post by William Hubbs
On 04/27/2018 08:45 AM, William Hubbs wrote:

> On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote:
>> On 04/26/2018 11:34 PM, Kent Fredric wrote:
>>> On Thu, 26 Apr 2018 13:35:15 -0700
>>> Zac Medico <[hidden email]> wrote:
>>>
>>>> emerge --depclean, resulting in an unbootable system. Just say-in.
>>>
>>> And depclean being very verbose doesn't do many favours here either.
>>>
>>> ( I regularly do >500 package depcleans and spotting things that aren't meant to be
>>>  culled amongst that list is a bit of a challenge )>
>>
>> At least for system packages, it will show a warning like the one shown
>> here:
>>
>>    https://bugs.gentoo.org/642484#c0
>>
>> Hopefully that message helps those that are paying enough attention.
>> What can we do for those that overlook the warning message, other than
>> give them some rescue instructions for making their system boot again?
>
> Another option suggested to me was to add a use flag to OpenRC that
> pulls in a dependency on virtual/init instead of adding virtual/init to
> @system. The suggestion originally was to add it to rdepend, but that
> doesn't feel right to me since openrc really doesn't have a runtime
> dependency on init, so I'm thinking something like this:
>
> IUSE="... +separate-init"
>
> PDEPEND="
> ...
> separate-init? ( virtual/init )"
>
> Thoughts?
Actually, if things like sys-apps/s6 or sys-process/runit remain as
choices for virtual/init, this isn't going to solve the problem of
sys-apps/sysvinit being removed by emerge --depclean. In fact, if
virtual/init is not in the system set, then emerge --depclean will not
even warn about removing a system package when it removes sys-apps/sysvinit.
--
Thanks,
Zac


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Rich Freeman
On Fri, Apr 27, 2018 at 2:18 PM Zac Medico <[hidden email]> wrote:

> Actually, if things like sys-apps/s6 or sys-process/runit remain as
> choices for virtual/init, this isn't going to solve the problem of
> sys-apps/sysvinit being removed by emerge --depclean. In fact, if
> virtual/init is not in the system set, then emerge --depclean will not
> even warn about removing a system package when it removes
sys-apps/sysvinit.

Well, at least we don't have to worry about users accidentally uninstalling
openssh, nano, or e2fsprogs (too bad if they use any other filesystem
though).  :)

In general we don't have a great way of telling portage what we're actually
using when various packages do more than one thing.  If you have busybox
installed you could conceivably remove a lot of other packages, but most
users don't actually intend for this to happen.

A USE flag that just pulls in a dep seems like the least evil solution
unless somebody wants to come up with a more general one.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: virtual/init for init process

Zac Medico-2
On 04/27/2018 11:43 AM, Rich Freeman wrote:

> On Fri, Apr 27, 2018 at 2:18 PM Zac Medico <[hidden email]> wrote:
>
>> Actually, if things like sys-apps/s6 or sys-process/runit remain as
>> choices for virtual/init, this isn't going to solve the problem of
>> sys-apps/sysvinit being removed by emerge --depclean. In fact, if
>> virtual/init is not in the system set, then emerge --depclean will not
>> even warn about removing a system package when it removes
> sys-apps/sysvinit.
>
> Well, at least we don't have to worry about users accidentally uninstalling
> openssh, nano, or e2fsprogs (too bad if they use any other filesystem
> though).  :)
>
> In general we don't have a great way of telling portage what we're actually
> using when various packages do more than one thing.  If you have busybox
> installed you could conceivably remove a lot of other packages, but most
> users don't actually intend for this to happen.
>
> A USE flag that just pulls in a dep seems like the least evil solution
> unless somebody wants to come up with a more general one.
A general solution might take the form of a standard interface for
interaction between eselect modules and package managers, as discussed
in this bug about telling the package manager which kernel you're using:

    https://bugs.gentoo.org/283587
--
Thanks,
Zac


signature.asc (201 bytes) Download Attachment