[gentoo-dev] rfc: virtual/init for init process

[gentoo-dev] rfc: virtual/init for init process

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 578 bytes --]

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



[-- Attachment #1.2: init-0.ebuild --]
[-- Type: text/plain, Size: 679 bytes --]

# 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=""

RDEPEND="
	!prefix? (
		kernel_linux? (
			|| (
				>=sys-apps/sysvinit-2.86-r6[selinux?]
				sys-apps/systemd
			)
			selinux? (
				>=sec-policy/selinux-base-policy-2.20170204-r4
			)
		)
		kernel_FreeBSD? (
			sys-freebsd/freebsd-sbin
		)
	)"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Jason Zaman]

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
> 		)
> 	)"

Re: [gentoo-dev] rfc: virtual/init for init process

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Michał Górny]

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

Re: [gentoo-dev] rfc: virtual/init for init process

[Mike Gilbert]

On Wed, Apr 25, 2018 at 3:20 PM, William Hubbs <williamh@gentoo.org> 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.

Re: [gentoo-dev] rfc: virtual/init for init process

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 152 bytes --]

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


[-- Attachment #1.2: init-0.ebuild --]
[-- Type: text/plain, Size: 795 bytes --]

# 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="selinux"

RDEPEND="
	!prefix? (
		kernel_linux? (
			|| (
				>=sys-apps/sysvinit-2.86-r6[selinux?]
				sys-apps/busybox[selinux?]
				sys-apps/openrc[selinux?]
				sys-apps/s6
				sys-apps/systemd[selinux?]
				sys-process/runit
			)
			selinux? (
				>=sec-policy/selinux-base-policy-2.20170204-r4
			)
		)
		kernel_FreeBSD? (
			sys-freebsd/freebsd-sbin
		)
	)"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 597 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Thu, 26 Apr 2018 13:35:15 -0700
Zac Medico <zmedico@gentoo.org> 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 )

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 783 bytes --]

On 04/26/2018 11:34 PM, Kent Fredric wrote:
> On Thu, 26 Apr 2018 13:35:15 -0700
> Zac Medico <zmedico@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] 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 <zmedico@gentoo.org> 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

Re: [gentoo-dev] rfc: virtual/init for init process

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

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 <zmedico@gentoo.org> 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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --]

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 <zmedico@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1502 bytes --]

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 <zmedico@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Mike Gilbert]

On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs <williamh@gentoo.org> 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 <zmedico@gentoo.org> 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.

Re: [gentoo-dev] rfc: virtual/init for init process

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

On Fri, Apr 27, 2018 at 12:28:43PM -0400, Mike Gilbert wrote:
> On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs <williamh@gentoo.org> 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 <zmedico@gentoo.org> 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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Mike Gilbert]

On Fri, Apr 27, 2018 at 1:28 PM, William Hubbs <williamh@gentoo.org> 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 <williamh@gentoo.org> 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 <zmedico@gentoo.org> 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.

Re: [gentoo-dev] rfc: virtual/init for init process

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1754 bytes --]

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 <zmedico@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] rfc: virtual/init for init process

[Rich Freeman]

On Fri, Apr 27, 2018 at 2:18 PM Zac Medico <zmedico@gentoo.org> 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

Re: [gentoo-dev] rfc: virtual/init for init process

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1367 bytes --]

On 04/27/2018 11:43 AM, Rich Freeman wrote:
> On Fri, Apr 27, 2018 at 2:18 PM Zac Medico <zmedico@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]