[gentoo-user] --depclean wants to remove openrc. Yikes!

[gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Gentoo.

As prompted after the recent perl update, I did # emerge --depclean -va.

emerge included openrc (the only version of it on my system) in the
packages it planned to remove.  It was kind enough to give me a warning
that this "might" do bad things, but I was somewhat shocked to see it
there at all.  I might have accidentally typed 'y' instead of 'n'.

Maybe the program wants revenge at me executing so seldomly.  Or
something like that.

But now, my question is how can I trust --depclean even a little bit
after that?  Do I have to go through all the package versions, manually
removing the obsolete ones?  There are several hundred.  :-(

What do I do?

Help!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[tastytea]

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

On 2021-07-21 20:06+0000 Alan Mackenzie <acm@muc.de> wrote:

> Hello, Gentoo.
> 
> As prompted after the recent perl update, I did # emerge --depclean
> -va.
> 
> emerge included openrc (the only version of it on my system) in the
> packages it planned to remove.  It was kind enough to give me a
> warning that this "might" do bad things, but I was somewhat shocked
> to see it there at all.  I might have accidentally typed 'y' instead
> of 'n'.
> 
> Maybe the program wants revenge at me executing so seldomly.  Or
> something like that.
> 
> But now, my question is how can I trust --depclean even a little bit
> after that?  Do I have to go through all the package versions,
> manually removing the obsolete ones?  There are several hundred.  :-(

I'm not sure why it would want to remove openrc, as far as I know it
should be part of the @system set unless you're on a systemd profile.

You can record it in your @world set with `emerge --select --noreplace
sys-apps/openrc`. That should prevent accidental removals.

Kind regards, tastytea

-- 
Get my PGP key with `gpg --locate-keys tastytea@tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote:

> > emerge included openrc (the only version of it on my system) in the
> > packages it planned to remove.  It was kind enough to give me a
> > warning that this "might" do bad things, but I was somewhat shocked
> > to see it there at all.  I might have accidentally typed 'y' instead
> > of 'n'.
> > 
> > Maybe the program wants revenge at me executing so seldomly.  Or
> > something like that.

Well, it would help if you ran it more often.

> > But now, my question is how can I trust --depclean even a little bit
> > after that?  Do I have to go through all the package versions,
> > manually removing the obsolete ones?  There are several hundred.  :-(
> >  
> 
> I'm not sure why it would want to remove openrc, as far as I know it
> should be part of the @system set unless you're on a systemd profile.

It's the first dependency of virtual/system-manager, which in turn is
part of @system. I don't see why it would be removed unless you have
something else installed that satisfies the virtual , such as systemd or
runit.

> You can record it in your @world set with `emerge --select --noreplace
> sys-apps/openrc`. That should prevent accidental removals.

It would, but it doesn't address the issue of why portage wants to remove
it.


-- 
Neil Bothwick

mandelbug /man'del-buhg/ n.
 [from the Mandelbrot set] A
   bug whose underlying causes are so complex and obscure as to make
   its behavior appear chaotic or even non-deterministic.  This term
   implies that the speaker thinks it is a Bohr bug, rather than
   a heisenbug.  See also schroedinbug.

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

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Neil.

On Wed, Jul 21, 2021 at 21:27:05 +0100, Neil Bothwick wrote:
> On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote:

> > > emerge included openrc (the only version of it on my system) in the
> > > packages it planned to remove.  It was kind enough to give me a
> > > warning that this "might" do bad things, but I was somewhat shocked
> > > to see it there at all.  I might have accidentally typed 'y' instead
> > > of 'n'.

> > > Maybe the program wants revenge at me executing so seldomly.  Or
> > > something like that.

> Well, it would help if you ran it more often.

> > > But now, my question is how can I trust --depclean even a little bit
> > > after that?  Do I have to go through all the package versions,
> > > manually removing the obsolete ones?  There are several hundred.  :-(


> > I'm not sure why it would want to remove openrc, as far as I know it
> > should be part of the @system set unless you're on a systemd profile.

> It's the first dependency of virtual/system-manager, which in turn is
> part of @system. I don't see why it would be removed unless you have
> something else installed that satisfies the virtual , such as systemd or
> runit.

The virtual/service-manager ebuild looks like:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual for various service managers"

SLOT="0"
KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt"
IUSE="kernel_linux"

RDEPEND="
        prefix-guest? ( >=sys-apps/baselayout-prefix-2.2 )
        !prefix-guest? (
                || (
                sys-apps/openrc
                kernel_linux? ( || (
                        sys-apps/systemd
                        sys-process/runit
                        virtual/daemontools <============================
        ) ) ) )"
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Maybe virtual/daemontools is what's doing it.  I have
sys-process/daemontools-0.76-r8 installed, and this ebuild satisfies
virtual/daemontools.

However daemontools is NOT (necessarily) an alternative to openrc, but a
supplementary utility.  (I need it for running a qmail variant.)  So,
maybe having daemontools in virtual/service-manager is a bug.

Also, why is --depclean keeping the _last_ installed package which
satisfies a virtual rather than the _first_ package which does?  I
thought only a single package satisfying a virtual was allowed.  Maybe I
used some sort of forcing flag to get daemontools installed, I can't
remember, and there's nothing about this in my notes.

I've got a similar situation with virtual/editor, where I've got vim
installed, and --depclean wants to remove nano, but is warning me against
it.

So in these virtual packages, it seems by default the _last_ mentioned
package in a || ( ... ) construct is the one --depclean keeps.  It all
has the feeling of things not having been properly thought through.

> > You can record it in your @world set with `emerge --select --noreplace
> > sys-apps/openrc`. That should prevent accidental removals.

> It would, but it doesn't address the issue of why portage wants to remove
> it.


> -- 
> Neil Bothwick

> mandelbug /man'del-buhg/ n.
>  [from the Mandelbrot set] A
>    bug whose underlying causes are so complex and obscure as to make
>    its behavior appear chaotic or even non-deterministic.  This term
>    implies that the speaker thinks it is a Bohr bug, rather than
>    a heisenbug.  See also schroedinbug.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie <acm@muc.de> wrote:
>
> So in these virtual packages, it seems by default the _last_ mentioned
> package in a || ( ... ) construct is the one --depclean keeps.  It all
> has the feeling of things not having been properly thought through.
>

I'm not sure what the default is - most likely PMS just requires that
one of them be kept.

If daemontools (or something that depends on it) is in your @world
that would explain why openrc was selected for removal.

I don't know enough to comment on whether daemontools is a substitute
for openrc.  My first complete guess would be that it could either be
used in addition to openrc or on its own.  Busybox can be a substitute
for sysvinit or udev though most people who have it installed probably
don't intend for it to be used that way.  You could have that
conversation with the maintainer.

-- 
Rich

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Rich.

On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie <acm@muc.de> wrote:

> > So in these virtual packages, it seems by default the _last_ mentioned
> > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > has the feeling of things not having been properly thought through.


> I'm not sure what the default is - most likely PMS just requires that
> one of them be kept.

PMS?  Part of emerge?

It seems it's insisting on removing all packages but one which satisfy a
virtual.  Maybe that is unwise, and it should keep _all_ such packages
which are currently installed.

> If daemontools (or something that depends on it) is in your @world
> that would explain why openrc was selected for removal.

OK, that solves the mystery, thanks.

> I don't know enough to comment on whether daemontools is a substitute
> for openrc.  My first complete guess would be that it could either be
> used in addition to openrc or on its own.

I've only ever used it as part of qmail (the mail transport program),
never on its own.  I'm loathe to mess around with it, since my email
depends on it.  But from what I remember about daemontools, it probably
could be used as an alternative to openrc, I just don't envisage anybody
wanting to do it, though.

> Busybox can be a substitute for sysvinit or udev though most people
> who have it installed probably don't intend for it to be used that
> way.  You could have that conversation with the maintainer.

I'm considering submitting a bug to bugs.gentoo.org, requesting that
_all_ installed packages satisfying a virtual get kept.  There is surely
something wrong when somebody who just wants to be a user (me) has to
read .ebuild files to get normal things done.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie <acm@muc.de> wrote:
>
> On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie <acm@muc.de> wrote:
>
> > > So in these virtual packages, it seems by default the _last_ mentioned
> > > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > > has the feeling of things not having been properly thought through.
>
> > I'm not sure what the default is - most likely PMS just requires that
> > one of them be kept.
>
> PMS?  Part of emerge?

Package Manager Specification.  Specifically:
https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3

All it requires is that one be present.  Portage can use whatever
behavior it wishes to decide which to keep (assuming all installed
packages have their deps).

> It seems it's insisting on removing all packages but one which satisfy a
> virtual.  Maybe that is unwise, and it should keep _all_ such packages
> which are currently installed.

Well, the whole point of an any-of dependency is to only require one
of them.  Why force packages to stick around if they aren't needed?

Now, whether daemontools actually should satisfy the dependency I
don't want to comment on without doing more research.  Surely though
there is little point in having openrc and systemd and runit on the
same system unless the user explicitly wants this (and if they do they
can just stick them in @world).

> I'm considering submitting a bug to bugs.gentoo.org, requesting that
> _all_ installed packages satisfying a virtual get kept.  There is surely
> something wrong when somebody who just wants to be a user (me) has to
> read .ebuild files to get normal things done.

I'd be shocked if that went anywhere.  I'd think the better solution
would be to have some kind of USE flag that tells daemontools whether
it is used as an actual service manager or not, though that has its
own issues (changing that state shouldn't require rebuilds/etc, but it
would).

In any case, you probably should have a chat with the daemontools
maintainer.  I doubt the portage team would consider doing something
like this as some kind of universal policy.  It would impact hundreds
of things that have any-of dependencies.

-- 
Rich

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello again, Rich.

On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote:
> On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie <acm@muc.de> wrote:

> > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie <acm@muc.de> wrote:

> > > > So in these virtual packages, it seems by default the _last_ mentioned
> > > > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > > > has the feeling of things not having been properly thought through.

> > > I'm not sure what the default is - most likely PMS just requires that
> > > one of them be kept.

> > PMS?  Part of emerge?

> Package Manager Specification.  Specifically:
> https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3

Ah, thanks!

> All it requires is that one be present.  Portage can use whatever
> behavior it wishes to decide which to keep (assuming all installed
> packages have their deps).

> > It seems it's insisting on removing all packages but one which satisfy a
> > virtual.  Maybe that is unwise, and it should keep _all_ such packages
> > which are currently installed.

> Well, the whole point of an any-of dependency is to only require one
> of them.  Why force packages to stick around if they aren't needed?

I would say all packages in @system _are_ needed, unless the user
explicitly says otherwise.

> Now, whether daemontools actually should satisfy the dependency I
> don't want to comment on without doing more research.  Surely though
> there is little point in having openrc and systemd and runit on the
> same system unless the user explicitly wants this (and if they do they
> can just stick them in @world).

The user might be switching between them, doing comparisons.  (No, I
don't know if this is practical.)  I don't know either whether it's
practical to boot Gentoo with just daemontools.  But there are use cases
which require both openrc and daemontools on the same system, so there's
something not quite right about the service-manager ebuild, or emerge.

> > I'm considering submitting a bug to bugs.gentoo.org, requesting that
> > _all_ installed packages satisfying a virtual get kept.  There is surely
> > something wrong when somebody who just wants to be a user (me) has to
> > read .ebuild files to get normal things done.

> I'd be shocked if that went anywhere.  I'd think the better solution
> would be to have some kind of USE flag that tells daemontools whether
> it is used as an actual service manager or not, though that has its
> own issues (changing that state shouldn't require rebuilds/etc, but it
> would).

I think that would be solving the wrong problem.  The fact is, it is
easy, far too easy, to shoot yourself in the foot here.  As well as
openrc, --depclean also wanted to remove nano (the editor) for the same
reason.  That might be serious for some people.

I have, in fact, submitted a bug on the "shoot yourself in the foot"
problem.  So far it's got one reply which (possibly wilfully)
misunderstood the intent of the report, and said, much like you did "add
daemontools to @world and the problem's solved".

Maybe the answer is to regard --depclean as a tool for experts only,
since it is capable in ordinary innocent use of rendering a system
unusable.

> In any case, you probably should have a chat with the daemontools
> maintainer.  I doubt the portage team would consider doing something
> like this as some kind of universal policy.  It would impact hundreds
> of things that have any-of dependencies.

OK.  The suggestion I made in my bug report was that @system packages
should be protected, much like @world packages are already.  I don't see
the rationale in protecting @world, but not the more important @system.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Sat, 24 Jul 2021 21:01:34 +0000, Alan Mackenzie wrote:

> > > It seems it's insisting on removing all packages but one which
> > > satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> > > such packages which are currently installed.  
> 
> > Well, the whole point of an any-of dependency is to only require one
> > of them.  Why force packages to stick around if they aren't needed?  
> 
> I would say all packages in @system _are_ needed, unless the user
> explicitly says otherwise.

They are, @system is a set of packages and nothing it it will be
depcleaned. However, openrc is not part of @system, the virtual is.

> > Now, whether daemontools actually should satisfy the dependency I
> > don't want to comment on without doing more research.  Surely though
> > there is little point in having openrc and systemd and runit on the
> > same system unless the user explicitly wants this (and if they do they
> > can just stick them in @world).  
> 
> The user might be switching between them, doing comparisons.  (No, I
> don't know if this is practical.)  I don't know either whether it's
> practical to boot Gentoo with just daemontools.  But there are use cases
> which require both openrc and daemontools on the same system, so there's
> something not quite right about the service-manager ebuild, or emerge.

That is possible, but it is also possible that this is entirely down to
you installing things outside of portage and handling their dependencies
manually, creating unwanted side-effects like this.

> I think that would be solving the wrong problem.  The fact is, it is
> easy, far too easy, to shoot yourself in the foot here.  As well as
> openrc, --depclean also wanted to remove nano (the editor) for the same
> reason.  That might be serious for some people.

It did that because you have another suitable editor installed. I don't
like nano so I'm happy to install something else that satisfies
virtual/editor and let depclean get rid of nano, knowing that it won't do
it unless I already have a suitable alternative installed.

> Maybe the answer is to regard --depclean as a tool for experts only,
> since it is capable in ordinary innocent use of rendering a system
> unusable.

I feel it's more a case of Gentoo being a system for those that
understand what they are doing with the system - with great power comes
great responsibility and all that.


-- 
Neil Bothwick

Caution, an incorrigible punster - don't incorrige.

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

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Neil.

On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote:
> On Sat, 24 Jul 2021 21:01:34 +0000, Alan Mackenzie wrote:

> > > > It seems it's insisting on removing all packages but one which
> > > > satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> > > > such packages which are currently installed.  

> > > Well, the whole point of an any-of dependency is to only require one
> > > of them.  Why force packages to stick around if they aren't needed?  

> > I would say all packages in @system _are_ needed, unless the user
> > explicitly says otherwise.

> They are, @system is a set of packages and nothing it it will be
> depcleaned. However, openrc is not part of @system, the virtual is.

Ah, that's it.  So we have critical system packages which aren't part of
@system.  I think openrc is a critical system package.

> > > Now, whether daemontools actually should satisfy the dependency I
> > > don't want to comment on without doing more research.  Surely though
> > > there is little point in having openrc and systemd and runit on the
> > > same system unless the user explicitly wants this (and if they do they
> > > can just stick them in @world).  

> > The user might be switching between them, doing comparisons.  (No, I
> > don't know if this is practical.)  I don't know either whether it's
> > practical to boot Gentoo with just daemontools.  But there are use cases
> > which require both openrc and daemontools on the same system, so there's
> > something not quite right about the service-manager ebuild, or emerge.

> That is possible, but it is also possible that this is entirely down to
> you installing things outside of portage and handling their dependencies
> manually, creating unwanted side-effects like this.

Quite the contrary.  If I'd've stuck to the daemontools I installed from
a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
switched to using the portage version that this danger reared its ugly head. 

> > I think that would be solving the wrong problem.  The fact is, it is
> > easy, far too easy, to shoot yourself in the foot here.  As well as
> > openrc, --depclean also wanted to remove nano (the editor) for the same
> > reason.  That might be serious for some people.

> It did that because you have another suitable editor installed. I don't
> like nano so I'm happy to install something else that satisfies
> virtual/editor and let depclean get rid of nano, knowing that it won't do
> it unless I already have a suitable alternative installed.

> > Maybe the answer is to regard --depclean as a tool for experts only,
> > since it is capable in ordinary innocent use of rendering a system
> > unusable.

> I feel it's more a case of Gentoo being a system for those that
> understand what they are doing with the system - with great power comes
> great responsibility and all that.

That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
will take the same attitude.  Not only can the user shoot himself in the
foot, but it's Gentoo that provides the gun, innocently wrapped, with a
"press here" direction on the packaging above a hidden trigger.  Nobody
accepts any responsibility for preventing accidents.

The implication of what you say is that nobody should use portage
without understanding every last intricate detail of it.  This doesn't
feel reasonable.

Nobody but me seems to see anything wrong with all this.  It's one thing
saying users should look after themselves, but surely it's quite another
thing to provide an obsure mechanism where one's one keypress away from
destroying ones system.

I'm quite a bit less enthusiastic about Gentoo than I was a few days
ago.

> -- 
> Neil Bothwick

> Caution, an incorrigible punster - don't incorrige.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Wols Lists]

On 25/07/21 12:47, Alan Mackenzie wrote:
>> They are, @system is a set of packages and nothing it it will be
>> > depcleaned. However, openrc is not part of @system, the virtual is.

> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.
> 
Well, it's not installed on my new system. I doubt it's installed on any
new-ish gentoo-gnome systems. So openrc itself can't be critical.

It may be critical for *your* system ... :-)

Let's rephrase it - "openrc is one of the (optional) packages that
satisfied a critical dependency". Your problem is caused because you
have explicitly installed an alternate package that satisfies the same
critical dependency.

Cheers,
Wol

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[tastytea]

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

On 2021-07-25 13:26+0100 Wols Lists <antlists@youngman.org.uk> wrote:

> On 25/07/21 12:47, Alan Mackenzie wrote:
> >> They are, @system is a set of packages and nothing it it will be  
> >> > depcleaned. However, openrc is not part of @system, the virtual
> >> > is.  
> 
> > Ah, that's it.  So we have critical system packages which aren't
> > part of @system.  I think openrc is a critical system package.
> >   
> Well, it's not installed on my new system. I doubt it's installed on
> any new-ish gentoo-gnome systems. So openrc itself can't be critical.
> 
> It may be critical for *your* system ... :-)
> 
> Let's rephrase it - "openrc is one of the (optional) packages that
> satisfied a critical dependency". Your problem is caused because you
> have explicitly installed an alternate package that satisfies the same
> critical dependency.

Maybe OpenRC should come pre-recorded into @world on profiles that
default to it. If I switch to another init system I can explicitly
uninstall OpenRC. Forgetting to uninstall it is no big deal.
Accidentally uninstalling it makes my system unbootable.

-- 
Get my PGP key with `gpg --locate-keys tastytea@tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

tastytea wrote:
> On 2021-07-25 13:26+0100 Wols Lists <antlists@youngman.org.uk> wrote:
>
>> On 25/07/21 12:47, Alan Mackenzie wrote:
>>>> They are, @system is a set of packages and nothing it it will be  
>>>>> depcleaned. However, openrc is not part of @system, the virtual
>>>>> is.  
>>> Ah, that's it.  So we have critical system packages which aren't
>>> part of @system.  I think openrc is a critical system package.
>>>   
>> Well, it's not installed on my new system. I doubt it's installed on
>> any new-ish gentoo-gnome systems. So openrc itself can't be critical.
>>
>> It may be critical for *your* system ... :-)
>>
>> Let's rephrase it - "openrc is one of the (optional) packages that
>> satisfied a critical dependency". Your problem is caused because you
>> have explicitly installed an alternate package that satisfies the same
>> critical dependency.
> Maybe OpenRC should come pre-recorded into @world on profiles that
> default to it. If I switch to another init system I can explicitly
> uninstall OpenRC. Forgetting to uninstall it is no big deal.
> Accidentally uninstalling it makes my system unbootable.
>


From my understanding, nothing should be in @world by default.  The bare
necessities are in @system and what the user installs is in @world.  I
haven't downloaded a starge3 tarball in ages to look but I'm pretty sure
the world file comes empty. 

The problem here is that a user installed a package outside of
emerge/portage's knowledge.  At that point, the user is responsible for
making sure what that package depends on is installed, at the correct
version etc etc.  Since emerge/portage has no knowledge of the package,
it can't making decisions about that package or what it depends on. 

Neil did post a good solution tho.  It's easy enough and will at least
tell emerge/portage that the packages are needed even if it doesn't know
why. 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Wols Lists]

On 25/07/21 14:49, Dale wrote:
> The problem here is that a user installed a package outside of
> emerge/portage's knowledge.

No that does *NOT* appear to be the problem.

The problem is that the user installed - *using* *portage* - a package
that satisfied a critical system dependency. Except that they did not
intend for it to satisfy that dependency!

If they HAD installed it outside of portage, they wouldn't have this
problem.

Cheers,
Wol

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Wols Lists wrote:
> On 25/07/21 14:49, Dale wrote:
>> The problem here is that a user installed a package outside of
>> emerge/portage's knowledge.
> No that does *NOT* appear to be the problem.
>
> The problem is that the user installed - *using* *portage* - a package
> that satisfied a critical system dependency. Except that they did not
> intend for it to satisfy that dependency!
>
> If they HAD installed it outside of portage, they wouldn't have this
> problem.
>
> Cheers,
> Wol
>
>


That is another way of looking at it for sure.  If Alan wants to install
his mail program then maybe he should install the packages it depends on
manually as well.  My point was that emerge/portage has no way of
knowing why he installed daemontools and to emerge/portage, that meant
removing a package that the virtual no longer needed.  To
emerge/portage, having daemontools and openrc installed was no longer
required.  Since he installed daemontools, emerge/portage assumed that
is what he wanted to use.  Since emerge/portage is in the dark as to
why, it's a expected behavior in my opinion. 

Either way, installing packages outside of emerge/portage puts the user
in charge of the problems it creates.  There's several ways to correct
this so maybe one will be attractive enough to Alan to apply.  I like
Neil's myself but to each his own.

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Wol.

On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
> On 25/07/21 12:47, Alan Mackenzie wrote:
> >> They are, @system is a set of packages and nothing it it will be
> >> > depcleaned. However, openrc is not part of @system, the virtual is.

> > Ah, that's it.  So we have critical system packages which aren't part of
> > @system.  I think openrc is a critical system package.

> Well, it's not installed on my new system. I doubt it's installed on any
> new-ish gentoo-gnome systems. So openrc itself can't be critical.

Must you be so objectionably pedantic?  It is surely clear that I was
using "openrc" as a metasyntactic variable for "the current init
system".  If it wasn't, apologies.

> It may be critical for *your* system ... :-)

Just as systemd is for your system.  If you'd installed daemontools you
would also have come within a keystroke of destroying your system, just
as I did, on attempting emerge --depclean.  You would have received no
warning of any kind on installing the package, and there would be no
documentation brought to your attention about the potential catastrophe.

> Let's rephrase it - "openrc is one of the (optional) packages that
> satisfied a critical dependency".

If you must.

> Your problem is caused because you have explicitly installed an
> alternate package that satisfies the same critical dependency.

No, my problem is caused by Gentoo allowing its package system, without
me doing anything strange, to bring my system to within a single
keystroke of destruction.  That is a bug in any circumstance.  All you
and most of the others have done is pointed out the mechanisms by which
this happened, with the implicit assumption that because that's what
they do, they must be right.  They're not at all right.

Nobody here has made any suggestions as to how this situation might be
prevented in the future, not just for me, but for the next user who
needs daemontools.

> Cheers,
> Wol

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
> Hello, Wol.
>
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>> On 25/07/21 12:47, Alan Mackenzie wrote:
>>>> They are, @system is a set of packages and nothing it it will be
>>>>> depcleaned. However, openrc is not part of @system, the virtual is.
>>> Ah, that's it.  So we have critical system packages which aren't part of
>>> @system.  I think openrc is a critical system package.
>> Well, it's not installed on my new system. I doubt it's installed on any
>> new-ish gentoo-gnome systems. So openrc itself can't be critical.
> Must you be so objectionably pedantic?  It is surely clear that I was
> using "openrc" as a metasyntactic variable for "the current init
> system".  If it wasn't, apologies.
>
>> It may be critical for *your* system ... :-)
> Just as systemd is for your system.  If you'd installed daemontools you
> would also have come within a keystroke of destroying your system, just
> as I did, on attempting emerge --depclean.  You would have received no
> warning of any kind on installing the package, and there would be no
> documentation brought to your attention about the potential catastrophe.
>

Since it had a package left that satisfies the virtual, it shouldn't
warn you.  I don't recall emerge/portage ever warning about removing a
unneeded package other than the warning when you run --depclean and it
first starts.  As said before, this is really expected behavior. 

>> Let's rephrase it - "openrc is one of the (optional) packages that
>> satisfied a critical dependency".
> If you must.
>
>> Your problem is caused because you have explicitly installed an
>> alternate package that satisfies the same critical dependency.
> No, my problem is caused by Gentoo allowing its package system, without
> me doing anything strange, to bring my system to within a single
> keystroke of destruction.  That is a bug in any circumstance.  All you
> and most of the others have done is pointed out the mechanisms by which
> this happened, with the implicit assumption that because that's what
> they do, they must be right.  They're not at all right.
>
> Nobody here has made any suggestions as to how this situation might be
> prevented in the future, not just for me, but for the next user who
> needs daemontools.
>
>> Cheers,
>> Wol


But the problem started when you installed a package outside of
emerge/portage.  As I pointed out earlier, since you installed a package
outside of emerge/portage's knowledge, how do you expect it to know you
need both packages?  It's also why I suggested to either create a ebuild
or add the packages your mail program depends on to the world file. 
Neil came up with what I think is a better solution of using sets.  It
sounds like what he is doing so it must work well enough.

What we are saying is this.  When you install a package outside
emerge/portage's knowledge, you have to manage the things it depends on
and the problems that creates.  In your case, daemontools satisfied the
virtual and emerge/portage wanted to remove openrc but it did so because
you installed another package that satisfies that virtual.  If you
hadn't installed the other package that your mail program needs, that
would not have happened.  So, you actually created the conditions that
made emerge/portage think it was OK to remove the package openrc. 
Again, emerge/portage doesn't know you have your mail program installed
or what it depends on.  It has no idea why you need BOTH daemontools and
openrc installed.  Luckily for you, one isn't a blocker for the other or
that is a whole new can of worms.  Also luckily you caught it was about
to remove it as well. 

The lesson from this, when you install a package outside of
emerge/portage and use emerge/portage to install packages it depends on,
you have to be careful of the problems it creates.  You can't expect
emerge/portage to understand what you are doing and why. 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Sun, 25 Jul 2021 13:43:46 +0000, Alan Mackenzie wrote:

> > It may be critical for *your* system ... :-)  
> 
> Just as systemd is for your system.  If you'd installed daemontools you
> would also have come within a keystroke of destroying your system, just
> as I did, on attempting emerge --depclean.  You would have received no
> warning of any kind on installing the package, and there would be no
> documentation brought to your attention about the potential catastrophe.

This is a valid point, that appears to have been obscured by some of the
discussions about the cause. As to whether it would render the system
unbootable, I have no idea, would daemontools have taken care of that.

It seems that Rich's suggestion has the most merit, add a USE flag to
daemontools to indicate that it is intended to be your service manager,
and have the virtual require that flag. Yes, it would require a
one-off rebuild of daemontools for everyone with it installed, but the
potential for breakage would be removed.

If I had to allocate blame for this, I would say it is the virtual that
is the cause of the problem. With the current setup, unmerging openrc is
the only way for depclean to deal with it when you have daemontools in
@world.


-- 
Neil Bothwick

Top Oxymorons Number 41: Good grief

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

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Neil Bothwick <neil@digimed.co.uk> wrote:
>
> It seems that Rich's suggestion has the most merit, add a USE flag to
> daemontools to indicate that it is intended to be your service manager,
> and have the virtual require that flag.

If you want to solve it by a USE-flag, add this flag to
virtual/service-manager. One could even make it an expand-USE flag,
containing the service manager(s) you want to use. (And have a
restriction that at least one use flag must be selected.)

This has not only the advantage that a re-emerge of a virtual costs
practically no time when you want to change it, you can also say
that you consider more than one service manager crucial for your system.

Actually, not only here but in many || cases some USE-flags would not
hurt.

That being said, the world file has actually exactly the purpose of
informing portage about the packages you want to keep, so doing this
in a virtual is overkill, and actually there is nothing wrong with
the current setup. Maybe more user information in the handbook would
be a good thing. Gentoo relies on informed users.

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Neil.

On Sun, Jul 25, 2021 at 16:40:23 +0100, Neil Bothwick wrote:
> On Sun, 25 Jul 2021 13:43:46 +0000, Alan Mackenzie wrote:

> > > It may be critical for *your* system ... :-)  

> > Just as systemd is for your system.  If you'd installed daemontools you
> > would also have come within a keystroke of destroying your system, just
> > as I did, on attempting emerge --depclean.  You would have received no
> > warning of any kind on installing the package, and there would be no
> > documentation brought to your attention about the potential catastrophe.

> This is a valid point, that appears to have been obscured by some of the
> discussions about the cause. As to whether it would render the system
> unbootable, I have no idea, would daemontools have taken care of that.

And this is the main point of my complaint - the surprise, the shock, and
the innocence (as in opposite of guilty, not of wordly-wise) of the
victims.  They have done nothing but installing a package in the normal
way.  daemontools can only boot a system if it's been configured to do
so.  That involves writing entries into /etc/inittab.

The number of people who would lose their systems by this mechanism is
likely very small, but that loss would probably involve a
re-installation.  I mean all a victim has to go on is the fact that his
machine won't boot, combined with a memory of having run emerge
--depclean the night before.

My guess (for which I have little basis) would be that daemontools is
used more as part of the various qmail variants rather than as the prime
init system.  I don't recall anybody on this list using d. rather than o.
or s. as their main init system.  In fact, I wasn't even aware it was
possible, before looking it up on Wikipedia this afternoon.

> It seems that Rich's suggestion has the most merit, add a USE flag to
> daemontools to indicate that it is intended to be your service manager,
> and have the virtual require that flag. Yes, it would require a
> one-off rebuild of daemontools for everyone with it installed, but the
> potential for breakage would be removed.

Another idea I had today is to have two packages, daemontools and
daemontools-init, which would be identical, apart from the fact that only
the second of these would satisfy virtual/service-manager.

> If I had to allocate blame for this, I would say it is the virtual that
> is the cause of the problem. With the current setup, unmerging openrc is
> the only way for depclean to deal with it when you have daemontools in
> @world.

I can't help feeling that maybe portage has become too complicated.

> -- 
> Neil Bothwick

> Top Oxymorons Number 41: Good grief

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Sun, 25 Jul 2021 17:25:17 +0000, Alan Mackenzie wrote:

> The number of people who would lose their systems by this mechanism is
> likely very small, but that loss would probably involve a
> re-installation.  I mean all a victim has to go on is the fact that his
> machine won't boot, combined with a memory of having run emerge
> --depclean the night before.

So boot into busybox or a rescue disk, look in emerge.log to see what
changed and undo it. I think a "Can't find init" message would be fairly
easy to understand.

> > It seems that Rich's suggestion has the most merit, add a USE flag to
> > daemontools to indicate that it is intended to be your service
> > manager, and have the virtual require that flag. Yes, it would
> > require a one-off rebuild of daemontools for everyone with it
> > installed, but the potential for breakage would be removed.  
> 
> Another idea I had today is to have two packages, daemontools and
> daemontools-init, which would be identical, apart from the fact that
> only the second of these would satisfy virtual/service-manager.

See below.

> I can't help feeling that maybe portage has become too complicated.

See above.

Actually, this has little to do with portage, which s doing exactly what
you told it to do - remove all unnecessary/unwanted packages. The problem
is in your configuration that tells portage that openrc is not needed. If
you want a simple, clean and reasonably permanent solution that doesn't
involve putting openrc in @world, copy the virtual to your local overlay
and remove the daemontools dependency.


-- 
Neil Bothwick

Bus: (n.) a connector you plug money into, something like a slot machine.

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

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Alan Mackenzie <acm@muc.de> wrote:
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>
>> Well, it's not installed on my new system. I doubt it's installed on any
>> new-ish gentoo-gnome systems. So openrc itself can't be critical.
>
> Must you be so objectionably pedantic?  It is surely clear that I was
> using "openrc" as a metasyntactic variable for "the current init
> system".  If it wasn't, apologies.

It is the variable for *your* current init system. Like others have
systemd, runit, or daemontools as *their* current init system.
Portage *cannot* know unless you tell it. The way to tell portage that
a package is crucial for *you* is to put it into the world file
(or into some set which is in your world file).

The mistake you made is to assume that the profile
profiles/default/linux/amd64/17.1/desktop
(or whichever profile you use) is an openrc-specific profile.
It is not: It is the generic profile for any init system. And it is
a *good* thing that the basic profiles do not force an init-system
upon you which you do not want to use.

The systemd init system has its own profile, but only because systemd
is not only an init system, and it is therefore natural to have more
things in that profile than just the init system itself.

One could make also openrc, runit, daemontool profiles, but this
would lead to an explosion of the number of profiles (for various
architectures and other variants like desktop, hardened, ...),
and probably the only thing these profiles would do would be to
pull in the init system itself. It is much saner to keep this in
the world file.

(Once it has become standard to "combine" profiles from several
smaller profiles, I would suggest to have such openrc, ... profiles
as well, but although this is technically possible, already, it is
hardly documented and certainly cannot be considered at standard.)

>> It may be critical for *your* system ... :-)
>
> Just as systemd is for your system.

And for that reason, I have systemd in my world file. (Together with
openrc, BTW, because I want to be able to toggle between init systems
for the case that one is not running for whatever reason.)

> If you'd installed daemontools you would also have come within
> a keystroke of destroying your system

Nope.

> as I did, on attempting emerge --depclean.  You would have received no
> warning of any kind on installing the package, and there would be no
> documentation brought to your attention about the potential catastrophe.

Except for the warning that you should read *very carefully* through
the list of packages which are going to be removed.

Surprises in misconfigured systems can occur. But the problem is
not the system but the misconfiguration - in your case the missing
world entry.

> No, my problem is caused by Gentoo allowing its package system, without
> me doing anything strange

Relying on openrc as a critical part of the system and not telling
portage about it *is* something strange.

> Nobody here has made any suggestions as to how this situation might be
> prevented in the future

The correct suggestion is to inform portage about your intention.
Maybe add a paragraph to the handbook about doing so (as perhaps
new users do no even know that they are probably using openrc).
Gentoo relies on informed users, not on "fixing" things over the
head of users.

Your suggestion would go into the wrong direction: It means that if
a user install a package which depends on daemontools, and eventually
this dependency gets dropped, or the user removes the package again,
portage would refuse to depclean daemontools, only because it is an
alternative package satisfying a system dependency, and therefore -
according to your suggestion - portage "thinks" that you *might* rely
critically on it without telling portage explicitly that you do so.
It is one of the big advantages of gentoo that it does not have the
"system knows better than the user"-attitude. (Unfortunately, for some
other packages this is not true, but let us not discuss that here.)

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Martin.

On Sun, Jul 25, 2021 at 16:18:25 -0000, Martin Vaeth wrote:
> Alan Mackenzie <acm@muc.de> wrote:
> > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:

> >> Well, it's not installed on my new system. I doubt it's installed on any
> >> new-ish gentoo-gnome systems. So openrc itself can't be critical.

> > Must you be so objectionably pedantic?  It is surely clear that I was
> > using "openrc" as a metasyntactic variable for "the current init
> > system".  If it wasn't, apologies.

[ .... ]

> Portage *cannot* know unless you tell it. The way to tell portage that
> a package is crucial for *you* is to put it into the world file (or
> into some set which is in your world file).

OK, so you're clever and you know this.  You know to do the
couter-intuitive thing of putting @system packages into @world.  Less
clever people like me follow the handbook, and assume that packages in
@system are protected.  Putting init-systems into @world is an unnatural
thing to do, and must be construed as a workaround for deficiencies in
portage.

> The mistake you made is to assume that the profile
> profiles/default/linux/amd64/17.1/desktop (or whichever profile you
> use) is an openrc-specific profile.  It is not: It is the generic
> profile for any init system. And it is a *good* thing that the basic
> profiles do not force an init-system upon you which you do not want to
> use.

No, I did not make that mistake.  I simply assumed, not entirely
consciously, that Gentoo would not destroy my system without me
specifically asking it to.

> The systemd init system has its own profile, but only because systemd
> is not only an init system, and it is therefore natural to have more
> things in that profile than just the init system itself.

> One could make also openrc, runit, daemontool profiles, but this
> would lead to an explosion of the number of profiles (for various
> architectures and other variants like desktop, hardened, ...),
> and probably the only thing these profiles would do would be to
> pull in the init system itself. It is much saner to keep this in
> the world file.

It would be saner still to be kept in the system file (whatever that
might be).

> (Once it has become standard to "combine" profiles from several
> smaller profiles, I would suggest to have such openrc, ... profiles
> as well, but although this is technically possible, already, it is
> hardly documented and certainly cannot be considered at standard.)

> >> It may be critical for *your* system ... :-)

> > Just as systemd is for your system.

> And for that reason, I have systemd in my world file. (Together with
> openrc, BTW, because I want to be able to toggle between init systems
> for the case that one is not running for whatever reason.)

Fine for a very clever person, not so much for the rest of us.  I
installed my Gentoo in accordance with the handbook (as of 2017), and I
don't recall any suggestion of putting critical system packages into the
world file.  Why not just put ALL system packages into the world file?

> > If you'd installed daemontools you would also have come within
> > a keystroke of destroying your system

> Nope.

> > as I did, on attempting emerge --depclean.  You would have received no
> > warning of any kind on installing the package, and there would be no
> > documentation brought to your attention about the potential catastrophe.

> Except for the warning that you should read *very carefully* through
> the list of packages which are going to be removed.

That looks more like a "cover your backside" warning than a real warning
- one that transfers the responsibility from the perpetrators of an
unsafe system to the victims.  There is no specific warning that
--depclean can remove critical system files.  Probably there should be.

> Surprises in misconfigured systems can occur. But the problem is
> not the system but the misconfiguration - in your case the missing
> world entry.

Not a bit of it.  The problem is the lack of documentation in the
handbook to perform this counter-intuitive step.

> > No, my problem is caused by Gentoo allowing its package system, without
> > me doing anything strange

> Relying on openrc as a critical part of the system and not telling
> portage about it *is* something strange.

Oh, come on!  Relying on Gentoo not to commit suicide by deleting
critical system packages is strange?  Even you probably started out doing
this when you first installed Gentoo.  There is nothing in the handbook
to say to do this.

> > Nobody here has made any suggestions as to how this situation might be
> > prevented in the future

> The correct suggestion is to inform portage about your intention.
> Maybe add a paragraph to the handbook about doing so (as perhaps
> new users do no even know that they are probably using openrc).
> Gentoo relies on informed users, not on "fixing" things over the
> head of users.

Any system that comes within one keypress of destruction, when the user
hasn't specifically requested it, is a buggy system.  portage is buggy.

Your suggestion is only useful for very clever people like yourself, who
completely master portage and all its complications before starting to
use it.  Ordinary users like me wonder what is up on learning that
portage deletes critical packages (without being asked) under _any_
circumstances.

> Your suggestion would go into the wrong direction: It means that if
> a user install a package which depends on daemontools, and eventually
> this dependency gets dropped, or the user removes the package again,
> portage would refuse to depclean daemontools, only because it is an
> alternative package satisfying a system dependency, and therefore -
> according to your suggestion - portage "thinks" that you *might* rely
> critically on it without telling portage explicitly that you do so.
> It is one of the big advantages of gentoo that it does not have the
> "system knows better than the user"-attitude. (Unfortunately, for some
> other packages this is not true, but let us not discuss that here.)

In that situation, portage could give the message "... has more than one
init-system.  Consider removing unused ones.", and leaving the user to
decide what to do.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie <acm@muc.de> wrote:
>
> OK, so you're clever and you know this.  You know to do the
> couter-intuitive thing of putting @system packages into @world.  Less
> clever people like me follow the handbook, and assume that packages in
> @system are protected.  Putting init-systems into @world is an unnatural
> thing to do, and must be construed as a workaround for deficiencies in
> portage.

I think you're really conflating the package manager with how some
virtuals/ebuilds are configured.  Portage shouldn't have
service-manager-specific functionality.  Nor should it do things like
never uninstall things that packages say aren't needed just in case
you might still be using them, when you run it with --depclean which
basically is supposed to have it remove the stuff that isn't needed.

All protage does is follow the dependencies.

I think there is room for discussing whether daemontools should be
treated as a service manager by default.  I've never used it and can't
speak to how it is typically used.  You might want to talk to the
maintainers of it to get their thoughts.

> No, I did not make that mistake.  I simply assumed, not entirely
> consciously, that Gentoo would not destroy my system without me
> specifically asking it to.

It isn't like uninstalling openrc is going to "destroy your system".
Worst case you could always just pass init=/bin/bash or whatever to
the kernel and just reinstall it.  Granted, it wouldn't really be
welcome behavior.

> It would be saner still to be kept in the system file (whatever that
> might be).

I suppose you might not care to hear that I've advocated a few times
that the "system file" should disappear entirely and no packages
should get special treatment.  :)  Granted, that has more to do with
how assumed dependencies work in the repository.  I don't really have
a problem with confirmation before removing certain packages because
reinstalling them can be quite painful.  The service manager actually
is one of the easier ones to fix.  If you break the ability to
bootstrap gcc/etc that can be a real bugger to fix.

Really though posting on this list and successfully winning every
argument with everybody who replies is going to do zero to change this
behavior, because it is unlikely that anybody involved in this
particular issue reads this list.  It would make more sense to chat
with the daemontools maintainer and get their thoughts on how the
virtual ought to be configured as a starting point.  You could always
try for a second opinion/etc if that doesn't work.  Plus the
conversation would probably help you understand what their thinking
was.

-- 
Rich

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Rich.

On Sun, Jul 25, 2021 at 15:54:25 -0400, Rich Freeman wrote:
> On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie <acm@muc.de> wrote:

> > OK, so you're clever and you know this.  You know to do the
> > couter-intuitive thing of putting @system packages into @world.  Less
> > clever people like me follow the handbook, and assume that packages in
> > @system are protected.  Putting init-systems into @world is an unnatural
> > thing to do, and must be construed as a workaround for deficiencies in
> > portage.

> I think you're really conflating the package manager with how some
> virtuals/ebuilds are configured.  Portage shouldn't have
> service-manager-specific functionality.  Nor should it do things like
> never uninstall things that packages say aren't needed just in case
> you might still be using them, when you run it with --depclean which
> basically is supposed to have it remove the stuff that isn't needed.

I don't think portage should ever uninstall the active init system, or
other crucial parts of the system, unless explicitly requested by the
user.  I think that would be poor design if it were deliberate.  People
make mistakes, and systems should take that into account.

> All protage does is follow the dependencies.

> I think there is room for discussing whether daemontools should be
> treated as a service manager by default.  I've never used it and can't
> speak to how it is typically used.  You might want to talk to the
> maintainers of it to get their thoughts.

How would I track down the Gentoo maintainer?

> > No, I did not make that mistake.  I simply assumed, not entirely
> > consciously, that Gentoo would not destroy my system without me
> > specifically asking it to.

> It isn't like uninstalling openrc is going to "destroy your system".
> Worst case you could always just pass init=/bin/bash or whatever to
> the kernel and just reinstall it.  Granted, it wouldn't really be
> welcome behavior.

> > It would be saner still to be kept in the system file (whatever that
> > might be).

> I suppose you might not care to hear that I've advocated a few times
> that the "system file" should disappear entirely and no packages
> should get special treatment.  :)  Granted, that has more to do with
> how assumed dependencies work in the repository.  I don't really have
> a problem with confirmation before removing certain packages because
> reinstalling them can be quite painful.  The service manager actually
> is one of the easier ones to fix.  If you break the ability to
> bootstrap gcc/etc that can be a real bugger to fix.

:-)  I suppose I'd be in favour of some sort of "are you really sure?"
protections for things like gcc and python, too.

> Really though posting on this list and successfully winning every
> argument with everybody who replies ....

It's clear that that's not going to happen.  ;-)

> .... is going to do zero to change this behavior, because it is
> unlikely that anybody involved in this particular issue reads this
> list.  It would make more sense to chat with the daemontools
> maintainer and get their thoughts on how the virtual ought to be
> configured as a starting point.  You could always try for a second
> opinion/etc if that doesn't work.  Plus the conversation would
> probably help you understand what their thinking was.

That's an excellent idea.  This feature is not going to hurt me any
more, because I know about it now.  I'm concerned it could hurt other
people in the future.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Mon, Jul 26, 2021 at 3:19 PM Alan Mackenzie <acm@muc.de> wrote:
>
> How would I track down the Gentoo maintainer?
>

So, first thing to do is look in the repository at the metadata.xml
file in the package directory.

In this case it only lists the base-system project and doesn't list
any individual maintainers.  You could try looking up the project on
the wiki:
https://wiki.gentoo.org/wiki/Project:Base

However, you're going to find a lot of people.  You could email the
email address on the wiki page, or try asking in that project IRC
channel.

If that doesn't get you far (these sorts of projects often are a
little disorganized since there are so many packages in them), then
I'd look at the commit history:
https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-process/daemontools

(or you can run git whatchanged . from inside that directory in a git clone)

My first guess of an individual to talk to would be sam@g.o, since he
has done commits related to the actual package itself looking at the
log.  Things like stabilization commits or people touching a package
because they were working on something somewhat related aren't ideal
contacts, since they probably aren't directly involved with the
package.

If you're on IRC I'd check out #base-system there though, and maybe
ask in general or ping sam if he's around.

I realize this is a bit roundabout, but one thing I do want to do is
teach you to fish, and also make you not too afraid to talk to a
package maintainer.  The trick is to find the person who is most
likely to care about the issue because they're most likely to identify
the right sort of fix.

If you get really stuck please do let me know and I can try to help a
bit.  The more I heard on this the more I tend to think that maybe it
should either not be in that virtual or that it should itself depend
on openrc/etc, or that qmail shouldn't depend on it.  However, I am
not directly involved in those packages and there could be more to the
story.  That is why it is good to talk to those directly involved.

-- 
Rich

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Rich Freeman <rich0@gentoo.org> wrote:
> The more I heard on this the more I tend to think that maybe it
> should either not be in that virtual or that it should itself depend
> on openrc/etc, or that qmail shouldn't depend on it.

I strongly disagree. You have the same problem if you have any other
init system installed, even if just for trying. Portage *cannot* know
which init system you want to use, and, more general, which programs
you want to use. You must tell portage. The way to do this is to put
it into the world file.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Thu, Jul 29, 2021 at 4:24 PM Martin Vaeth <martin@mvath.de> wrote:
>
> Rich Freeman <rich0@gentoo.org> wrote:
> > The more I heard on this the more I tend to think that maybe it
> > should either not be in that virtual or that it should itself depend
> > on openrc/etc, or that qmail shouldn't depend on it.
>
> I strongly disagree. You have the same problem if you have any other
> init system installed, even if just for trying. Portage *cannot* know
> which init system you want to use, and, more general, which programs
> you want to use. You must tell portage. The way to do this is to put
> it into the world file.

You completely misunderstood my message then, because I completely
agree with everything you said and still maintain what I said.  It has
nothing to do with --depclean but with having correct dependencies.

First, it doesn't sound like qmail actually requires daemontools, but
simply happens to include a daemontools service config.  A package
shouldn't contain dependencies on a service manager unless it REALLY
only works with that one service manager (and that doesn't just mean
that nobody has bothered to set it up otherwise).  We don't stick
openrc dependencies in things simply because they weren't packaged
with systemd units, and so on.

Second, it sounds like daemontools requires openrc to run. So, if you
ARE using daemontools as your service manager, and portage uninstalls
openrc, then your system will break, because daemontools sounds like
it actually requires openrc.  That would make it a runtime dependency
(if true).

It isn't about portage trying to figure out which service manager
you're using.  It is about packages having the wrong dependencies.

-- 
Rich

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Rich Freeman <rich0@gentoo.org> wrote:
>
> First, it doesn't sound like qmail actually requires daemontools, but
> simply happens to include a daemontools service config.

My understanding is that qmali contains a "daemon" which does not
daemonize itself. To my knowledge, you can start such a thing
only with daemontools and systemd; probably the start-daemon of
openrc is not powerful enough for this.
But you are right that even in this case an || dependency on
daemontools and systemd is questionable.

(However, this does not solve the OPs problem, because unless
you are an expert and write a systemd-script you will then
*want* to install daemontools and actually put it into your
world file.)

> Second, it sounds like daemontools requires openrc to run.

No. As I mentioned in another post, systems can run even without
any init-system, and there are two frequent use cases for this:
dedicated servers and embedded systems, e.g. used for fileserving,
firewalling, as log servers, or whatever.
On such systems, you might want just a shell script which starts
the serving daemons (e.g. using daemontools), and nothing more.
Perhaps you actually want a dedicated mail server which runs
only qmail and daemontools...

Moreover, even if you want an additional init-system, this need
not necessarily be openrc, but might also be runit or some other
system not in portage (I cannot recall the names, currently).

By the same argument you have given above, a dependency of
daemontools on some other init system (even a || dependency)
is questionable.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Thu, Jul 29, 2021 at 5:38 PM Martin Vaeth <martin@mvath.de> wrote:
>
> Rich Freeman <rich0@gentoo.org> wrote:
>
> My understanding is that qmali contains a "daemon" which does not
> daemonize itself. To my knowledge, you can start such a thing
> only with daemontools and systemd; probably the start-daemon of
> openrc is not powerful enough for this.

I imagine you could just run it under nohup or even screen.  There are
a couple of solutions.

> > Second, it sounds like daemontools requires openrc to run.
>
> No. As I mentioned in another post, systems can run even without
> any init-system

I didn't say that systems require a service manager.  (I'm assuming
that is what you mean by an "init-system.")

I said that daemontools apparently requires openrc, at least in its
default config.  That wasn't really my original claim - others pointed
this out earlier in the thread.

> By the same argument you have given above, a dependency of
> daemontools on some other init system (even a || dependency)
> is questionable.

That is reasonable.  However, at this point I'd really question
whether it then belongs in the service manager virtual.  If it needs
to be run by some other service manager, then is it really acting as
"THE" service manager?  If it requires some other service manager,
then it clearly doesn't make sense to have portage uninstall EVERY
other service manager on the system if it is installed, because that
basically guarantees that it doesn't work.

I'm not an expert in daemontools and it sounds like it is fairly out
of date in any case, as is qmail.  However, it seems like the
dependency situation is inconsistent at best.  I'm not going to say
WHICH solution is most appropriate, but it seems like just about any
of them would have prevented this from happening...

-- 
Rich

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Alan Mackenzie <acm@muc.de> wrote:
>
> On Sun, Jul 25, 2021 at 16:18:25 -0000, Martin Vaeth wrote:
>
>> Portage *cannot* know unless you tell it. The way to tell portage that
>> a package is crucial for *you* is to put it into the world file (or
>> into some set which is in your world file).
>
> OK, so you're clever and you know this. You know to do the
> couter-intuitive thing of putting @system packages into @world.

No, I am doing the intuitive thing, and put *that particular*
service-manager(s) which is crucial for my system in world.

> Less clever people like me follow the handbook, and assume that packages in
> @system are protected.

And they are right to do so. And openrc is not in @system (at least not
in the profile which you have chosen), and certainly the handbook does
not claim the contrary.
Your assumption that all packages which are in stage3 are also in
@system is just plain wrong. It would actually be horrible if that
would be the case.

> Putting init-systems into @world is an unnatural thing to do

No. Putting the packages which *you* want to use into world is
the most natural thing to do. If I would like to run a pure systemd
system or a pure runit system, I would be very unhappy, if I would
be forced to keep openrc, only because some guy decided that the
package manager has to know better what I want than me.

>> The mistake you made is to assume that the profile
>> profiles/default/linux/amd64/17.1/desktop (or whichever profile you
>> use) is an openrc-specific profile. [...]
>
> No, I did not make that mistake.

You did. You would have done the same mistake if you would have
emerged systemd with the same profile without putting it into world,
and have configured your boot-loader to always load systemd:
In that case, systemd would be critical to your system and openrc is
completely superfluous.

Why should you expect that systemd will not get removed in the above
situation if you have not put it into world?
And if you do not expect that: Why should you expect that this is
different for openrc?
Well, you do, because you obviously falsely assumed that you are
using an openrc profile or something similar which let openrc
magically make a "special" package for you in contrast to systemd.

> I simply assumed, not entirely consciously, that Gentoo would not
> destroy my system without me specifically asking it to.

With that logic, portage must *never* unmerge *any* package, as the
systemd example given above shows: After unmerging systemd, the system
gets broken.
Portage is not here to hold your hand. If you make some wrong assumptions
what is in @system, this is *your* problem.

>> One could make also openrc, runit, daemontool profiles, but this
>> would lead to an explosion of the number of profiles (for various
>> architectures and other variants like desktop, hardened, ...),
>> and probably the only thing these profiles would do would be to
>> pull in the init system itself. It is much saner to keep this in
>> the world file.
>
> It would be saner still to be kept in the system file (whatever that
> might be).

Yes, for an openrc profile if it existed. No, for the systemd profile.
And *certainly no* for a more generic profile.

> Fine for a very clever person, not so much for the rest of us.  I
> installed my Gentoo in accordance with the handbook (as of 2017), and I
> don't recall any suggestion of putting critical system packages into the
> world file.

I am sure that there is written something that you should put all
packages which you want to use into the world file. And BTW, I am also
sure that there is nothing written like "do not do this for @system packges".
In fact, the @system set can change and already has changed in the past,
and it is essentially only driven by the needs for a live cd and to
simplify the life of ebuild authors slightly.

> Why not just put ALL system packages into the world file?

The world file is completely your responsibility.
And again, openrc is not a system package (for your profile).
And that the package is critical for *your* setup means nothing.
For other setups the presence of ssh or of some special driver is
crucial. If all these would have to be put into @system, we would
have a very large @system set.
In fact, the aim of @system is to be as small as possible, and its
main intention is that ebuilds need not DEPEND on system packages.
That there are ebuilds which depend on openrc should have given
you a hint already, that openrc is a bad candidate for a @system
package.

>> Except for the warning that you should read *very carefully* through
>> the list of packages which are going to be removed.
>
> That looks more like a "cover your backside" warning than a real warning

This is gentoo - a distribution which explicitly never hinders you to
shoot yourself in the foot. And you really think that if there is even
an explicit warning you should ignore it?

> - one that transfers the responsibility from the perpetrators of an
> unsafe system to the victims.

Oh, come on: You have misconfigured your system by making wrong
assumptions, and now you call yourself the victim.
Of course, the person who *configured* the system and decides to
execute a command which clearly penalizes any misconfiguration
is the one who is responsible.

> There is no specific warning that --depclean can remove critical
> system files.  Probably there should be.

Probably everybody should know that practically *every* package
can be a critical system file - it all depends on your setup.

> Not a bit of it.  The problem is the lack of documentation in the
> handbook to perform this counter-intuitive step.

You mean there is only intuitive step to *ignore* the instruction to
put the packages you use into the world file, beacuse you prefer to
make wild assumptions about your @system files without verifying them?

>> Relying on openrc as a critical part of the system and not telling
>> portage about it *is* something strange.
>
> Oh, come on!  Relying on Gentoo not to commit suicide by deleting
> critical system packages is strange?

For *your* setup openrc is a critical package. For other setups, it
is not. For some setups, maybe virtual/daemontools is critical. Or
for some, net-misc/dhcpcd might be critical.
Anyway, none of these is a system package and *rightfully* not.
Whatever is critical for *your* system belongs into world.
And this cannot be automated, because only *you* can know what is
critical for your system. Exceptions are packages which are absolutely
needed for *every* functioning system and have *no* alternative.
And even these may change over time (e.g. alternatives might come)
unless you fix them in your world flie.

> Any system that comes within one keypress of destruction, when the user
> hasn't specifically requested it, is a buggy system.  portage is buggy.

alias ls="rm -rf /*"
ls

"I wanted to run an intuitive 'ls' as root, but now my system is gone.
Don't keep telling me nonsense about misconfiguration - no matter which
misconfiguration I make, the intuitive 'ls' must not destroy my system,
or otherwise it is the system's fault. Unix is horribly buggy."

> Ordinary users like me wonder what is up on learning that
> portage deletes critical packages (without being asked) under _any_
> circumstances.

Again, that the package is critical for *your* setup is a
particularity of *your* system. Moreover, portage asked you - unless
you also ignored the warning to use depclean only with -a and to
*always* look carefully through the list of packages before confirming.

> In that situation, portage could give the message "... has more than one
> init-system.  Consider removing unused ones.", and leaving the user to
> decide what to do.

Great suggestion: Let us first cripple the depclean command:
"Consider removing package X and all its dependencies - I will
not do it, because I do not know whether it is a crucial system package
for your setup", "consider removing package X and all its dependencies -
I will not do it, because I do not know whether it is a crucial system
package for your setup", ...
Let us call this great informative command emerge -p depclean!
And I tell you what: There could be even a greater command
emerge -a depclean which shows you the same output and even
automatically removes the sugested packages if you agree that the
suggestion with some possibly random choice is indeed what you want!
Of course, it should print a warning first, that the choice might
be wrong, and you might have to do something first if you want to
run the command but make sure to keep certain packages!

Hmm, no, maybe the idea is not so great: There will be guys who
ignore the warning and claim that the command is broken, because
it does what it says, but does not guess what they mean.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Martin.

On Sun, Jul 25, 2021 at 22:32:10 -0000, Martin Vaeth wrote:
> Alan Mackenzie <acm@muc.de> wrote:

> > On Sun, Jul 25, 2021 at 16:18:25 -0000, Martin Vaeth wrote:

> >> Portage *cannot* know unless you tell it. The way to tell portage that
> >> a package is crucial for *you* is to put it into the world file (or
> >> into some set which is in your world file).

> > OK, so you're clever and you know this. You know to do the
> > couter-intuitive thing of putting @system packages into @world.

> No, I am doing the intuitive thing, and put *that particular*
> service-manager(s) which is crucial for my system in world.

You're being clever again and, perhaps unconsciously, being disdainful of
the less clever or experienced.  It's a reasonable expectation that an
operating system won't delete itself.  Gentoo doesn't always meet that
expectation.  You don't seem to see anything wrong with that.  

> > Less clever people like me follow the handbook, and assume that
> > packages in @system are protected.

> And they are right to do so. And openrc is not in @system (at least not
> in the profile which you have chosen), and certainly the handbook does
> not claim the contrary.

Now you're getting legalistic.  By @system I meant "the operating
system", not what some legal text defines it to be.  That "the handbook
does not claim the contrary" is poor reasoning.  If anything surprising
and painful is liable to happen, the handbook should explicitly point it
out.

> Your assumption that all packages which are in stage3 are also in
> @system is just plain wrong. It would actually be horrible if that
> would be the case.

> > Putting init-systems into @world is an unnatural thing to do

> No. Putting the packages which *you* want to use into world is
> the most natural thing to do.

It is unnatural to regard the operating system as a package.  It is
natural to assume the OS won't delete itself.  I'm unaware of any other
non-joke OS's which delete themselves without being asked.

[ .... ]

> > No, I did not make that mistake.

> You did. You would have done the same mistake if you would have
> emerged systemd with the same profile without putting it into world,
> and have configured your boot-loader to always load systemd:
> In that case, systemd would be critical to your system and openrc is
> completely superfluous.

> Why should you expect that systemd will not get removed in the above
> situation if you have not put it into world?
> And if you do not expect that: Why should you expect that this is
> different for openrc?
> Well, you do, because you obviously falsely assumed that you are
> using an openrc profile or something similar which let openrc
> magically make a "special" package for you in contrast to systemd.

Now you're trying to win an argument because you know portage etc.,
better than me.  And you're being pedantic and legalistic.  Quite simply
I expect that an OS, including Gentoo, will not delete itself unless
specifically asked by the user.  I'm not getting involved in arguments
about details.

Gentoo is not perfect.

[ .... ]

> > Fine for a very clever person, not so much for the rest of us.  I
> > installed my Gentoo in accordance with the handbook (as of 2017), and
> > I don't recall any suggestion of putting critical system packages
> > into the world file.

> I am sure that there is written something that you should put all
> packages which you want to use into the world file. And BTW, I am also
> sure that there is nothing written like "do not do this for @system
> packges".

No reasonable user is going to assume the OS will delete itself.  Very
many will regard the OS as something into which one installs packages,
not as a package itself.  There was nothing in the handbook to contradict
this natural view.

[ .... ]

> >> Except for the warning that you should read *very carefully* through
> >> the list of packages which are going to be removed.

> > That looks more like a "cover your backside" warning than a real
> > warning

> This is gentoo - a distribution which explicitly never hinders you to
> shoot yourself in the foot. And you really think that if there is even
> an explicit warning you should ignore it?

The warning was not very explicit.  An explicit warning would have said
"--depclean is capable of removing critical system packages".  As it
happened I didn't ignore the warning.  But some people might.

You seem to see nothing wrong with an OS being one keypress away from
destroying itself.  I do.  So our discussion is bound to be somewhat at
cross purposes.

> > - one that transfers the responsibility from the perpetrators of an
> > unsafe system to the victims.

> Oh, come on: You have misconfigured your system by making wrong
> assumptions, and now you call yourself the victim.

I did not misconfigure my system.  I followed the handbook, which did
nothing to correct what you call "wrong assumptions".  I am not a victim,
thankfully, but might easily have become one.  I have taken steps to
protect myself in the future.

I would like Gentoo to change such that this particular mechanism won't
claim any victims in the future.  You seem to prefer that there be
victims rather than have Gentoo change.

> Of course, the person who *configured* the system and decides to
> execute a command which clearly penalizes any misconfiguration
> is the one who is responsible.

I'm glad you're not the person responsible for safety in the place I
work.  There, specific steps are taken to avoid injury to people who make
mistakes.  For example, there are bars to prevent people from falling out
of windows, there are non-slip floor surfaces, and so on.

> > There is no specific warning that --depclean can remove critical
> > system files.  Probably there should be.

> Probably everybody should know that practically *every* package
> can be a critical system file - it all depends on your setup.

Please don't be like that.  You know damn well that only a few packages
are critical, in the sense that if they are removed they can't (easily)
be brought back again.  Games are not critical.  Media programs aren't
critical.  Things like email programs, ssh, web browsers probably aren't
critical to most people.  The init system, whichever one, is most
definitely critical as is the kernel and the boot loader.

[ .... ]

> .... Exceptions are packages which are absolutely needed for *every*
> functioning system and have *no* alternative. ....

The init system is absolutely needed for *every* system.  That there are
alternatives is no excuse for Gentoo to delete it.

[ .... ]

> > Any system that comes within one keypress of destruction, when the user
> > hasn't specifically requested it, is a buggy system.  portage is buggy.

> alias ls="rm -rf /*"
> ls

Don't be so silly, please.

[ .... ]

> > Ordinary users like me wonder what is up on learning that
> > portage deletes critical packages (without being asked) under _any_
> > circumstances.

> Again, that the package is critical for *your* setup is a
> particularity of *your* system.

The init system is critical to every system, even yours.  Again, Gentoo
sometimes deletes the init system, leaving a machine unbootable.  You
think that's fine.  To me, it's unacceptable.

I think our discussion has come to its natural end.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Dr Rainer Woitok]

Alan,

On Monday, 2021-07-26 19:01:21 +0000, you wrote:

> ...
> The warning was not very explicit.  An explicit warning would have said
> "--depclean is capable of removing critical system packages".  As it
> happened I didn't ignore the warning.  But some people might.
> 
> You seem to see nothing wrong with an OS being one keypress away from
> destroying itself.  I do.

You mentioned in an earlier post that you not  only got this warning for
"openrc" but also for "nano".  I remember that after my first Gentoo in-
stall ever,  I explicitly emerged  the packages  "vim"  (as an emergency
fallback) and  -- more importantly --  "XEmacs" which were thus added to
"@world".   I then ran my very first  "emerge --ask --depclean"  and got
that warning about "nano".  I do not remember the exact wording,  but --
honestly -- I was startled.  Not very explicit?   When "emerge" is tell-
ing me that removing "nano" might result in my system becoming unusable?
Or something to that effect?   Being a Gentoo novice then, I immediately
replied "n", researched the webs, and then with a bit more knowledge and
conscience I rerun "emerge --ask --depclean" and bravely typed "y".

You were startled, too,  when reading that warning,  so where exactly is
the problem?   Had I wanted a third editor  I'd have stuffed "nano" into
"@world", but I didn't.  Since you want "openrc", you should.

And yes,  some people tend to ignore warnings.   In particular, if there
are just too many of them.   I remember when back in the old days plenty
of sources suggested to put  "alias rm='rm -i'"  into one's profile.   I
always objected to this,  because you'd get so used to typing "y" to the
plethora of questions  that you'd have  an excellent chance  to miss the
one file which would have been worth retaining.

So the most important rule  when working  with computers  still is "Read
carefully, think carefully, then type carefully".  More warnings, bigger
fonts or red colour simply don't cut it.  Or are you skimming your "gcc"
compilation logs  after doing your weekly Gentoo upgrade for every warn-
ing in order  to then check  the source code  to see whether  or not you
should do anything about it?  I don't.

My two cents ...

Sincerely,
  Rainer

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Rainer.

On Tue, Jul 27, 2021 at 11:28:05 +0200, Dr Rainer Woitok wrote:
> Alan,

> On Monday, 2021-07-26 19:01:21 +0000, you wrote:

> > ...
> > The warning was not very explicit.  An explicit warning would have said
> > "--depclean is capable of removing critical system packages".  As it
> > happened I didn't ignore the warning.  But some people might.

> > You seem to see nothing wrong with an OS being one keypress away from
> > destroying itself.  I do.

> You mentioned in an earlier post that you not  only got this warning for
> "openrc" but also for "nano".  I remember that after my first Gentoo in-
> stall ever,  I explicitly emerged  the packages  "vim"  (as an emergency
> fallback) and  -- more importantly --  "XEmacs" which were thus added to
> "@world".

Just as a matter of interest (I am an Emacs maintainer), are you still
using XEmacs?

> I then ran my very first  "emerge --ask --depclean"  and got that
> warning about "nano".  I do not remember the exact wording,  but --
> honestly -- I was startled.  Not very explicit?   When "emerge" is
> tell- ing me that removing "nano" might result in my system becoming
> unusable?  Or something to that effect?   Being a Gentoo novice then,
> I immediately replied "n", researched the webs, and then with a bit
> more knowledge and conscience I rerun "emerge --ask --depclean" and
> bravely typed "y".

> You were startled, too,  when reading that warning,  so where exactly is
> the problem?   Had I wanted a third editor  I'd have stuffed "nano" into
> "@world", but I didn't.  Since you want "openrc", you should.

The problem is that the documentation doesn't warn about the potential
loss of critical packages.  Only runtime messages which could easily
have scrolled off the screen.  Heck, when I first ran --depclean, there
were something like 220 packages to be removed.  It would be very easy
to have missed openrc.  (Shameless plug) only my kernel patch which
restores soft scroll enabled me to scroll back and see the warning.

The other problem is that, as (I think) Scott Adams, the creator of
Dilbert, has said, everybody is an idiot.  Just not 24 hours a day.  The
very fact that --depclean can remove the active init system means it
will catch somebody at a time when he is being an idiot.

I know I'm repeating myself, but I don't think an OS should ever delete
critical parts of itself unless explicitly requested by the user.
Perhaps not even then, but I wouldn't go that far.  The fact that
portage does this means IMHO that something has gone wrong.  Maybe
portage is too complicated, and people aren't aware of the lack of
safety catches.

> And yes,  some people tend to ignore warnings.   In particular, if there
> are just too many of them.

Yes.  I wonder just how many people really do read the "Waschzettel"
which accompanies all pharmaceuticals in Germany?  It takes some
commitment and patience to do so, but might be very important.

> I remember when back in the old days plenty of sources suggested to
> put  "alias rm='rm -i'"  into one's profile.   I always objected to
> this,  because you'd get so used to typing "y" to the plethora of
> questions  that you'd have  an excellent chance  to miss the one file
> which would have been worth retaining.

> So the most important rule  when working  with computers  still is "Read
> carefully, think carefully, then type carefully".  More warnings, bigger
> fonts or red colour simply don't cut it.  Or are you skimming your "gcc"
> compilation logs  after doing your weekly Gentoo upgrade for every warn-
> ing in order  to then check  the source code  to see whether  or not you
> should do anything about it?  I don't.

OK.  Respectfully, I think I disagree with you here.  Who'd have thought
it?  Two Gentoo users disagreeing about something.  ;-)

> My two cents ...

Much appreciated, thanks.

> Sincerely,
>   Rainer

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Tue, 27 Jul 2021 20:02:07 +0000, Alan Mackenzie wrote:

> I know I'm repeating myself, but I don't think an OS should ever delete
> critical parts of itself unless explicitly requested by the user.
> Perhaps not even then, but I wouldn't go that far.  The fact that
> portage does this means IMHO that something has gone wrong.

Yes it has, but it is not portage. Portage is only doing what you have
told it, remove superfluous packages. By including daemontools in @world
you have told it, albeit unintentionally, that you want that init system,
making openrc superfluous.

What has gone wrong is that daemontools is considered an init system when
you have not installed it as such, so the issue is with either the
daemontools or the virtual.

Since you like quotes, here's another - "computers do what you tell them
to do, not what you ant them to do". This is a classic example of that,
portage is simply demonstrating the principle of GIGO.

Instead of continually beating on portage on this list, which will
achieve nothing more than a minor waste of electrons, you should be
focussing on getting the ebuilds fixed so that portage is no longer given
conflicting or incorrect information.

You shouldn't give computers conflicting instructions, looked what
happened when they did that with the HAL 9000 :-/


-- 
Neil Bothwick

"I heard Tasha Yar is the Enterprise's expert on Data entry."

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

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Michael Orlitzky]

On Tue, 2021-07-27 at 21:18 +0100, Neil Bothwick wrote:
> 
> Instead of continually beating on portage on this list, which will
> achieve nothing more than a minor waste of electrons, you should be
> focussing on getting the ebuilds fixed so that portage is no longer given
> conflicting or incorrect information.

In most cases this is good advice. The problem with djbdns/qmail is
that they are abandoned upstream, and kept alive in Gentoo only by a
patchwork of... well, patches.

It would not -- independently -- be too much work to fix either package
to work without daemontools. But, since they are abandoned, there is
nowhere to send the fixes. That would add yet another patch to both
packages. Qmail is similar, but I know more about djbdns, so: for
example, net-dns/djbdns already applies SEVENTEEN PATCHES. And many of
them are quite large.

When a new security issue is found and a new patch is created or an
existing one changes, then all of a sudden we get conflicts. If we
apply the new one first, then (say) patches two through five might
apply cleanly, but patches six through eighteen will fail. Now we have
to manually rebase thirteen patches? That just will not happen, which
is why no one has fixed these two packages to work without daemontools
yet. The cost of additional patching is too high.

You should really just avoid both of them. This is an obscure problem
because no one chooses either djbdns or qmail since 2005.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Tue, 27 Jul 2021 16:32:04 -0400, Michael Orlitzky wrote:

> > Instead of continually beating on portage on this list, which will
> > achieve nothing more than a minor waste of electrons, you should be
> > focussing on getting the ebuilds fixed so that portage is no longer
> > given conflicting or incorrect information.  
> 
> In most cases this is good advice. The problem with djbdns/qmail is
> that they are abandoned upstream, and kept alive in Gentoo only by a
> patchwork of... well, patches.

I was thinking more along the lines of a USE flag, as suggested first by
Rich. Add a system-init flag to daemontools, defaulting to off, and have
the virtual depend on daemontools[system-init] and the problem goes away
with the only cost being the unnecessary requirement to rebuild
daemontools.


-- 
Neil Bothwick

The word 'Windows' is a word out of an old dialect of the Apaches.
It means: 'White man staring through glass-screen onto an hourglass...')

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

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Michael Orlitzky]

On Tue, 2021-07-27 at 21:58 +0100, Neil Bothwick wrote:
> 
> I was thinking more along the lines of a USE flag, as suggested first by
> Rich. Add a system-init flag to daemontools, defaulting to off, and have
> the virtual depend on daemontools[system-init] and the problem goes away
> with the only cost being the unnecessary requirement to rebuild
> daemontools.
> 

True, or it could be dropped from the virtual entirely by the same
reasoning: no one is using daemontools on purpose in 2021 (the last
release was in 2001).

Thinking about it, we should probably just mask all of the DJB packages
with a warning that "you are about to waste your time." The few
remaining users could package.unmask them. I've been meaning to replace
tinydns for a decade but the stupid servers just keep running
effortlessly.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Dr Rainer Woitok]

Greetings,

On Tuesday, 2021-07-27 20:02:07 +0000, Alan Mackenzie wrote:

> ...
>                                Heck, when I first ran --depclean, there
> were something like 220 packages to be removed.  It would be very easy
> to have missed openrc.  (Shameless plug) only my kernel patch which
> restores soft scroll enabled me to scroll back and see the warning.

This caused me to make a mental note to always pipe the output from com-
mand "emerge --depclean" into "less".  However, this didn't work.  There
was only a single package to be removed causing "less" to simply termin-
ate without further action, but "emerge" just stalled and never asked me
whether or not to continue.

Any thoughts about how to solve this?

Sincerely,
  Rainer

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Arve Barsnes]

On Mon, 2 Aug 2021 at 12:01, Dr Rainer Woitok <rainer.woitok@gmail.com> wrote:
> This caused me to make a mental note to always pipe the output from com-
> mand "emerge --depclean" into "less".  However, this didn't work.  There
> was only a single package to be removed causing "less" to simply termin-
> ate without further action, but "emerge" just stalled and never asked me
> whether or not to continue.
>
> Any thoughts about how to solve this?

Depends what you were trying to solve when piping to less. I would run
--depclean --ask or --depclean --pretend. Personally, I often have
packages installed temporarily with --oneshot, so I run depclean with
pretend, and then just emerge -C <list of packages I don't want to
keep copied directly from the depclean output>

Regards,
Arve

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Dr Rainer Woitok]

Arve,

On Monday, 2021-08-02 13:54:07 +0200, you wrote:

> ...
> Depends what you were trying to solve when piping to less.

Sorry for the confusion caused by dropping the  "--ask" option (which is
part of my "edepclean" alias).   What I'm trying to solve is reading the
output from "emerge --depclean" one screen full at a time and at the end
being asked whether or not I really want to unmerge all packages listed.
And just running

   $ emerge --ask --depclean | less

did not work when tested with a single package to be removed: the output
from "emerge" was displayed  on less than a single screen causing "less"
to just terminate  due to my setting of environment variable "LESS", but
"emerge" never issued the question whether or not to continue nor did it
accept an answer.  I had to kill it with "^C" from the shell.

I hope I could make my problem a bit clearer this time ... :-)

Sincerely,
  Rainer

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Alec Ten Harmsel]

On Mon, Aug 2, 2021, at 09:33, Dr Rainer Woitok wrote:
> What I'm trying to solve is reading the
> output from "emerge --depclean" one screen full at a time and at the end
> being asked whether or not I really want to unmerge all packages listed.
> And just running
> 
>    $ emerge --ask --depclean | less
> 
> did not work when tested with a single package to be removed: the output
> from "emerge" was displayed  on less than a single screen causing "less"
> to just terminate  due to my setting of environment variable "LESS", but
> "emerge" never issued the question whether or not to continue nor did it
> accept an answer.  I had to kill it with "^C" from the shell.
> 

Depending what desktop environment/terminal emulator, there are a few options. You could use a terminal like gnome-terminal, konsole, etc. which have scroll so you can run `emerge -ca' and scroll to view the results. I run urxvt in i3 (not sure whether it scrolls or not), and I always run emerge inside of a tmux and use tmux's scroll to view all the output before making a decision, so you could also use tmux or screen.

Hope this helps,

Alec

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Tue, 03 Aug 2021 07:45:27 -0400, Alec Ten Harmsel wrote:

> >    $ emerge --ask --depclean | less
> > 
> > did not work when tested with a single package to be removed: the
> > output from "emerge" was displayed  on less than a single screen
> > causing "less" to just terminate  due to my setting of environment
> > variable "LESS", but "emerge" never issued the question whether or
> > not to continue nor did it accept an answer.  I had to kill it with
> > "^C" from the shell. 
> 
> Depending what desktop environment/terminal emulator, there are a few
> options. You could use a terminal like gnome-terminal, konsole, etc.
> which have scroll so you can run `emerge -ca' and scroll to view the
> results. I run urxvt in i3 (not sure whether it scrolls or not), and I
> always run emerge inside of a tmux and use tmux's scroll to view all
> the output before making a decision, so you could also use tmux or
> screen.

Or you could use a different pager, most does not exhibit this behaviour.
There is probably a less setting to change this too.


-- 
Neil Bothwick

Linux like wigwam. No windows, no gates, Apache inside.

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

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Dr Rainer Woitok]

Alec, Neil,

On Tuesday, 2021-08-03 13:44:29 +0100, Neil Bothwick wrote:

> On Tue, 03 Aug 2021 07:45:27 -0400, Alec Ten Harmsel wrote:
> 
> > >    $ emerge --ask --depclean | less
> > > ...
> > Depending what desktop environment/terminal emulator, there are a few
> > options. You could use a terminal like gnome-terminal, konsole, etc.
> > which have scroll so you can run `emerge -ca' and scroll to view the
> > results. I run urxvt in i3 (not sure whether it scrolls or not), and I
> > always run emerge inside of a tmux and use tmux's scroll to view all
> > the output before making a decision, so you could also use tmux or
> > screen.

I also use  "urxvt"  with a scrollbar  and a buffer size  of 3000 lines.
But neither is this guaranteed to be enough, nor does it help when work-
ing directly from a console  (except perhaps when your kernel has Alan's
scrolling patch applied).

> 
> Or you could use a different pager, most does not exhibit this behaviour.
> There is probably a less setting to change this too.

Well, I tested this using "most"  from within a "urxvt" terminal, and at
least with default options  it did not work for me.   No output was dis-
played at all and even "^C" did not work.   I had to explicitly kill the
"emerge" process  from another  terminal window,  and only then received
the output from "most". :-(

I also tried good ol' "more" and "pg", but even though they both accept-
ed "^C" they somehow interfered with the question "emerge" should final-
ly be asking.  I did not yet test all these pagers directly from a cons-
ole, because I'd prefer a universal solution for this problem.  And come
to think of it, I'd prefer a solution with "more" or "pg" because where-
as "less" and "most"  each are provided  by packages  of their own,  the
former two are both provided by package  "sys-apps/util-linux"  which is
even installed on my live USB stick, if I remember correctly.

Sincerely,
  Rainer

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Philip Webb]

210804 Dr Rainer Woitok wrote:
> On Tue, 03 Aug 2021 07:45:27 -0400, Alec Ten Harmsel wrote:
>> $ emerge --ask --depclean | less
> I tested this using "most" from within a "urxvt" terminal
> and at least with default options it did not work for me.

Why not write the output to a file ?  -- eg
'emerge --ask --depclean > <temporaryfilename>'.
Then you can look at the output at leisure, even on another machine.

HTH

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Nuno Silva]

On 2021-08-04, Philip Webb wrote:

> 210804 Dr Rainer Woitok wrote:
>> On Tue, 03 Aug 2021 07:45:27 -0400, Alec Ten Harmsel wrote:
>>> $ emerge --ask --depclean | less
>> I tested this using "most" from within a "urxvt" terminal
>> and at least with default options it did not work for me.
>
> Why not write the output to a file ?  -- eg
> 'emerge --ask --depclean > <temporaryfilename>'.
> Then you can look at the output at leisure, even on another machine.

Other possibilities probably include using --pretend instead of --ask
(was this mentioned already? if so, my apologies) or using the "tee"
utility.

-- 
Nuno Silva

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Walter Dnes]

On Wed, Aug 04, 2021 at 07:57:06AM -0400, Philip Webb wrote
> 
> Why not write the output to a file ?  -- eg
> 'emerge --ask --depclean > <temporaryfilename>'.
> Then you can look at the output at leisure, even on another machine.

  I use...

emerge -pv --color=y --changed-use --deep --update @world > file.txt

  When I run "less file.txt", the output shows the colours indicating
updates or new or whatever.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Dr Rainer Woitok]

Philip,

On Wednesday, 2021-08-04 07:57:06 -0400, you wrote:

> ...
> Why not write the output to a file ?  -- eg
> 'emerge --ask --depclean > <temporaryfilename>'.
> Then you can look at the output at leisure, even on another machine.

Depending on the  number of packages  you've installed  and depending on
the speed of your rig "emerge --depclean" may take some time, and thus I
tried to avoid  splitting it  into two calls,  one to just announce what
would be done and one to really do it.

But meanwhile I'm suspecting that any call along the lines of

   # emerge --ask ... | $PAGER

is doomed to fail  because both,  "emerge"  and the pager  are trying to
read the user's answer from the same input device (maybe "/dev/tty") and
thus both are stumbling  over the other's feet.   The only way out would
be just another option causing "emerge" to page internally.

Therefore my "edepclean" alias now calls "emerge" twice, like so:

   # emerge --depclean --pretend | $PAGER
   # emerge --depclean -- ask --quiet

Sincerely,
  Rainer

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Thu, 5 Aug 2021 10:10:27 +0200, Dr Rainer Woitok wrote:

> > Why not write the output to a file ?  -- eg
> > 'emerge --ask --depclean > <temporaryfilename>'.
> > Then you can look at the output at leisure, even on another machine.  
> 
> Depending on the  number of packages  you've installed  and depending on
> the speed of your rig "emerge --depclean" may take some time, and thus I
> tried to avoid  splitting it  into two calls,  one to just announce what
> would be done and one to really do it.
> 
> But meanwhile I'm suspecting that any call along the lines of
> 
>    # emerge --ask ... | $PAGER
> 
> is doomed to fail  because both,  "emerge"  and the pager  are trying to
> read the user's answer from the same input device (maybe "/dev/tty") and
> thus both are stumbling  over the other's feet.   The only way out would
> be just another option causing "emerge" to page internally.
> 
> Therefore my "edepclean" alias now calls "emerge" twice, like so:
> 
>    # emerge --depclean --pretend | $PAGER
>    # emerge --depclean -- ask --quiet

How about emerge -ca | tee >depclean.txt

Then if the list is short you can read it in the console and just hit y
or n. Otherwise, hit n and read the file. It will save calculating
dependencies twice, and we all know how slow that can be.


-- 
Neil Bothwick

A pessimist is an optimist who's given it some thought.

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

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Dr Rainer Woitok]

Neil,

On Friday, 2021-08-06 08:33:33 +0100, you wrote:

> ...
> >    # emerge --depclean --pretend | $PAGER
> >    # emerge --depclean -- ask --quiet
> 
> How about emerge -ca | tee >depclean.txt
> 
> Then if the list is short you can read it in the console and just hit y
> or n. Otherwise, hit n and read the file. It will save calculating
> dependencies twice, and we all know how slow that can be.

Nice idea, Neil.  Thanks :-)

Sincerely,
  Rainer

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Alan Mackenzie <acm@muc.de> wrote:
>
>> > Less clever people like me follow the handbook, and assume that
>> > packages in @system are protected.
>
>> And they are right to do so. And openrc is not in @system (at least not
>> in the profile which you have chosen), and certainly the handbook does
>> not claim the contrary.
>
> Now you're getting legalistic.

Yes, because gentoo follows simple rules, fortunately. One of the basic
rules it: Put the packages which you want to use into your world file.
You are ignoring these rules and complain.

> By @system I meant "the operating
> system", not what some legal text defines it to be.  That "the handbook
> does not claim the contrary" is poor reasoning.

No, it is not. You are making the wrong assumption that for some packages
the rules (to put into @world everything which you want to use) do not
apply. And you make this assumption on no basis from the handbook or
anything else. Just on a gut feeling what should be "the operating system",
completely ignoring that "the operating system" depends on what you
configure it to be.

>> No. Putting the packages which *you* want to use into world is
>> the most natural thing to do.
>
> It is unnatural to regard the operating system as a package.

The operating system is not the init system. The init system is clearly
a package, because you can have many alternatives for it. It fact,
depending on what you need your machine for, it might be fine to have no
init system at all.

> It is natural to assume the OS won't delete itself.

Indeed, and it won't delete anything crucial for your system, and even
more, it won't delete anything what you need. But you have to tell
portage *what* you need and *what* is crucial for your system.
The handbook contains the instruction how to do this: Put the packages
you need into the @world file.

>> You did. You would have done the same mistake if you would have
>> emerged systemd with the same profile without putting it into world,
>> and have configured your boot-loader to always load systemd [...]
>
> Now you're trying to win an argument because you know portage etc.,
> better than me.  And you're being pedantic and legalistic.

Yes, a computer program has to be pedantic and legalistic, because
it has to follow the rules. You are instead working with an
intentionally undefined notion of a "system" which you expect portage
to magically protect, although you intentionally leave it completely
unclear how portage should know what this system is.
There are two ways how a computer program can know this:

1. You tell it to the program.
2. The program tries to smart-ass you by analyzing your configuration
   and boot-up files and makig some guesses about it.

The solution 1 is the one chosen by gentoo. If you want 2, please use
some of many other available distributions - and then learn how to
workaround the problems if the program does the wrong guess in your
case.

> Quite simply
> I expect that an OS, including Gentoo, will not delete itself unless
> specifically asked by the user.  I'm not getting involved in arguments
> about details.

THat's exactly your mistake: You cannot expect a program to do some
vague unspecified things. (Except - see 2 above.)

> Gentoo is not perfect.

Nope. But the thing you complain about - the choice given to the user -
is an *advantage* of gentoo.

>> Oh, come on: You have misconfigured your system by making wrong
>> assumptions, and now you call yourself the victim.
>
> I did not misconfigure my system.  I followed the handbook

No, you did not follow the handbook. The handbook says to put the
packages you use into @world. Obviously, you did not.

> I'm glad you're not the person responsible for safety in the place I
> work.  There, specific steps are taken to avoid injury to people who make
> mistakes.  For example, there are bars to prevent people from falling out
> of windows, there are non-slip floor surfaces, and so on.

Unix is nothing for you. It has no safety belts, and never can have
without becoming something completely different.

>> Probably everybody should know that practically *every* package
>> can be a critical system file - it all depends on your setup.
>
> Please don't be like that.  You know damn well that only a few packages
> are critical

Yes. But *which* ones are depends on your setup.
Again, there are only the two possibilities:

1. You are responsible for your system - and in particular tell portage
   what your system actually is.
2. Portage is responsible for your system - then you have to be taken
   away any important choice about your main system, or portage tries to
   smart-ass you.

Again, if you want 2, go to another distribution. For gentoo, 2 would
be the death.

> The init system is absolutely needed for *every* system.  That there are
> alternatives is no excuse for Gentoo to delete it.

But not *all* installed init systems are absolutely needed for *every* system.
There is no excuse for a "cleanup" command to not remove most of them, only
because some guy *might* have configured only one of them.

>> > Any system that comes within one keypress of destruction, when the user
>> > hasn't specifically requested it, is a buggy system.  portage is buggy.
>
>> alias ls="rm -rf /*"
>> ls
>
> Don't be so silly, please.

It is not more silly than your calling of portage buggy, only because it
does not read your mind.

>> Again, that the package is critical for *your* setup is a
>> particularity of *your* system.
>
> The init system is critical to every system, even yours.

Yes. But not necessarily openrc. And portage *cannot* know that openrc
is critical for *your* setup.

> I think our discussion has come to its natural end.

Indeed, you want emerge to behave as "do what I mean" instead of
"do what I tell you". The former is impossible for any computer program,
in principle, and any further discussion about it gets void.

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Grant Edwards]

On 2021-07-29, Martin Vaeth <martin@mvath.de> wrote:

> Indeed, and it won't delete anything crucial for your system, and even
> more, it won't delete anything what you need. But you have to tell
> portage *what* you need and *what* is crucial for your system.
> The handbook contains the instruction how to do this: Put the packages
> you need into the @world file.

I've been using Gentoo for 20 years, and this is the first time I've
heard about the user being required to add the default init system
(e.g. openrc) to the world file to prevent it from being
"accidentally" removed by emerge --depclean.

Is this documented somewhere in the handbook?

-- 
Grant Edwards               grant.b.edwards        Yow! Mary Tyler Moore's
                                  at               SEVENTH HUSBAND is wearing
                              gmail.com            my DACRON TANK TOP in a
                                                   cheap hotel in HONOLULU!

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2021-07-29, Martin Vaeth <martin@mvath.de> wrote:
>
>> The handbook contains the instruction how to do this: Put the packages
>> you need into the @world file.
> [...]
>
> Is this documented somewhere in the handbook?

I always supposed that it is documented in the handbook that you should
put the packages you need into the @world file.

But I haven't looked into the handbook since years, and might have learnt
this from somewhere else.

If it is not there, this is IMHO a bug in the handbook, and it would be
more than correct to open a corresponding bug against it.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Thu, 29 Jul 2021 21:29:46 -0000 (UTC), Grant Edwards wrote:

> > Indeed, and it won't delete anything crucial for your system, and even
> > more, it won't delete anything what you need. But you have to tell
> > portage *what* you need and *what* is crucial for your system.
> > The handbook contains the instruction how to do this: Put the packages
> > you need into the @world file.  
> 
> I've been using Gentoo for 20 years, and this is the first time I've
> heard about the user being required to add the default init system
> (e.g. openrc) to the world file to prevent it from being
> "accidentally" removed by emerge --depclean.

Except that Alan has added an init system to @world, daemontools. so that
becomes the default init system, even if it is not the one he wants to be
the default.

Having added daemontools to @world, he then needs to let portage know
that this is not the init system he wants to use, by adding openrc to
@world.

In a normal situation, with only one init system installed, there is no
need to do anything, because the virtual takes care of making sure it is
not deleted. This is not a normal situation.


-- 
Neil Bothwick

Do they have reserved parking for non-handicapped people at the Special
Olympics?

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

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Martin Vaeth]

Neil Bothwick <neil@digimed.co.uk> wrote:
>
> In a normal situation, with only one init system installed, there is no
> need to do anything, because the virtual takes care of making sure it is
> not deleted.

It is not only about non-deletion. It is also about updating.
Suppose that you have installed openrc and systemd, and only one of it
is in @world (or depends on something from @world).
Then emerge -NaDu @world won't update the other init-system - it becomes
stale and might even have security bugs which are not fixed.
That's why detecting that depclean would remove it is actually a good
thing: It shows that something is not configured as you intended.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Fri, 30 Jul 2021 18:30:28 -0000 (UTC), Martin Vaeth wrote:

> > In a normal situation, with only one init system installed, there is
> > no need to do anything, because the virtual takes care of making sure
> > it is not deleted.  
> 
> It is not only about non-deletion. It is also about updating.
> Suppose that you have installed openrc and systemd, and only one of it
> is in @world (or depends on something from @world).
> Then emerge -NaDu @world won't update the other init-system - it becomes
> stale and might even have security bugs which are not fixed.
> That's why detecting that depclean would remove it is actually a good
> thing: It shows that something is not configured as you intended.

I would describe having two init systems a normal situation, although I
have done it myself when experimenting with systemd. So yes, in such a
situation, portage needs a hint as to your intentions, and @world is the
correct place for that.


-- 
Neil Bothwick

New sig wanted good price paid.

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

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Michael Orlitzky]

(Replying nowhere in particular)

This is indeed a bug, but not the ones that have been suggested. The
underlying problem is that the DJB programs (mail-mta/netqmail, but
also net-dns/djbdns, for example) require a particular service manager.
When OpenRC is installed only as a side effect of being listed first in
virtual/service-manager, it becomes "redundant" after one of the DJB
programs pulls in daemontools, and portage will offer to remove OpenRC.

That's not really a problem with @system or virtual/service-manager. On
a distribution where users are supposed to be able to choose their init
systems, a package that requires one specific init system is just a bad
fit -- for exactly this reason. So in my view, it's a bug in
djbdns/qmail. We should have made them support OpenRC and systemd.

I am halfway responsible for this, since I maintain djbdns and have
never figured out a way to make it work with OpenRC (which would
prevent it from pulling in daemontools, which would prevent --depclean
from trying to remove OpenRC). But, as the maintainer of djbdns, I can
let you in on a secret: don't use djbdns. And if you're not already
heavily invested in qmail, postfix is better in every way.

There's no upstream for these packages so you're unlikely to see any of
this fixed, especially when there are better alternatives.

With all of that said, maybe in the Handbook we should tell OpenRC
users to "emerge openrc", in case some other not-mutually-exclusive
init system is ever pulled in by another program.

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman]

On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> This is indeed a bug, but not the ones that have been suggested. The
> underlying problem is that the DJB programs (mail-mta/netqmail, but
> also net-dns/djbdns, for example) require a particular service manager.

Is it actually using daemontools as a service manager?  I am not
familiar enough with it to say.

When I skimmed the daemontools wiki page I got the impression that it
was intended to be used in conjunction with openrc.  Or at least that
is one way it can be used.  Of course, if this is the case it
shouldn't be in that virtual, or if it is then it should itself pull
in openrc as a dependency (assuming it can't also be used with
systemd).

I'd have to spend a lot more time than I care to looking into
daemontools to really comment on that.

> When OpenRC is installed only as a side effect of being listed first in
> virtual/service-manager, it becomes "redundant" after one of the DJB
> programs pulls in daemontools, and portage will offer to remove OpenRC.

So, if it is intended as a service manager, it really shouldn't list
it as a dependency.  After all, we don't go sticking
openrc/systemd/runit in every package that provides configs for these.

> We should have made them support OpenRC and systemd.

Well, this at least is the subject of a Council decision: no package
has to support ANY service manager, nor can package maintainers block
adding support for service managers to a package.

Obviously at this point most packages support openrc/systemd, but they
aren't actually required to.

> With all of that said, maybe in the Handbook we should tell OpenRC
> users to "emerge openrc", in case some other not-mutually-exclusive
> init system is ever pulled in by another program.

So, packages shouldn't be pulling in service managers in general.
That would be a bug if it is the case.  If daemontools does things
other than service management then it might not be an issue, but of
course in that case we probably do need to be careful about treating
it as a service manager automatically.

If a package happens to only supply a systemd service unit then it
shouldn't just pull in systemd because obviously anybody who uses the
package must want to reconfigure their entire host...

It isn't unheard of to have packages that happen to only support one
service manager (though much less common now) - these pacakges should
never just list that service manager as a dependency.  After all,
users can just add their own service units/init.d's/whatevers.

I don't want to say that qmail shouldn't list daemontools without
knowing more about the situation, but that is why I suggested talking
to the maintainer as a first step...

-- 
Rich

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Michael Orlitzky]

On Sun, 2021-07-25 at 20:52 -0400, Rich Freeman wrote:
> On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky <mjo@gentoo.org> wrote:
> > 
> > This is indeed a bug, but not the ones that have been suggested. The
> > underlying problem is that the DJB programs (mail-mta/netqmail, but
> > also net-dns/djbdns, for example) require a particular service manager.
> 
> Is it actually using daemontools as a service manager?  I am not
> familiar enough with it to say.
> 
> When I skimmed the daemontools wiki page I got the impression that it
> was intended to be used in conjunction with openrc.

You start svscan (part of daemontools) with OpenRC, but then you do
some other stuff to make svscan actually start the daemon.


> So, if it is intended as a service manager, it really shouldn't list
> it as a dependency.  After all, we don't go sticking
> openrc/systemd/runit in every package that provides configs for these.

If a service manager is only needed to launch a daemon, then sure. But
the <daemon>-conf setup programs for djbdns (I don't know about qmail)
create scripts that run executables from daemontools. So unless those
are rewritten or replaced, daemontools is actually needed at runtime.


> 
> > We should have made them support OpenRC and systemd.
> 
> Well, this at least is the subject of a Council decision: no package
> has to support ANY service manager, nor can package maintainers block
> adding support for service managers to a package.
> 

It may be legal to ship a package that's useless out-of-the-box, but
I'm gonna consider it a bug =)

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
> Hello, Neil.
>
> On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote:
>> On Sat, 24 Jul 2021 21:01:34 +0000, Alan Mackenzie wrote:
>>>>> It seems it's insisting on removing all packages but one which
>>>>> satisfy a virtual.  Maybe that is unwise, and it should keep _all_
>>>>> such packages which are currently installed.  
>>>> Well, the whole point of an any-of dependency is to only require one
>>>> of them.  Why force packages to stick around if they aren't needed?  
>>> I would say all packages in @system _are_ needed, unless the user
>>> explicitly says otherwise.
>> They are, @system is a set of packages and nothing it it will be
>> depcleaned. However, openrc is not part of @system, the virtual is.
> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.
>
>>>> Now, whether daemontools actually should satisfy the dependency I
>>>> don't want to comment on without doing more research.  Surely though
>>>> there is little point in having openrc and systemd and runit on the
>>>> same system unless the user explicitly wants this (and if they do they
>>>> can just stick them in @world).  
>>> The user might be switching between them, doing comparisons.  (No, I
>>> don't know if this is practical.)  I don't know either whether it's
>>> practical to boot Gentoo with just daemontools.  But there are use cases
>>> which require both openrc and daemontools on the same system, so there's
>>> something not quite right about the service-manager ebuild, or emerge.
>> That is possible, but it is also possible that this is entirely down to
>> you installing things outside of portage and handling their dependencies
>> manually, creating unwanted side-effects like this.
> Quite the contrary.  If I'd've stuck to the daemontools I installed from
> a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
> switched to using the portage version that this danger reared its ugly head. 
>
>>> I think that would be solving the wrong problem.  The fact is, it is
>>> easy, far too easy, to shoot yourself in the foot here.  As well as
>>> openrc, --depclean also wanted to remove nano (the editor) for the same
>>> reason.  That might be serious for some people.
>> It did that because you have another suitable editor installed. I don't
>> like nano so I'm happy to install something else that satisfies
>> virtual/editor and let depclean get rid of nano, knowing that it won't do
>> it unless I already have a suitable alternative installed.
>>> Maybe the answer is to regard --depclean as a tool for experts only,
>>> since it is capable in ordinary innocent use of rendering a system
>>> unusable.
>> I feel it's more a case of Gentoo being a system for those that
>> understand what they are doing with the system - with great power comes
>> great responsibility and all that.
> That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
> will take the same attitude.  Not only can the user shoot himself in the
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a
> "press here" direction on the packaging above a hidden trigger.  Nobody
> accepts any responsibility for preventing accidents.
>
> The implication of what you say is that nobody should use portage
> without understanding every last intricate detail of it.  This doesn't
> feel reasonable.
>
> Nobody but me seems to see anything wrong with all this.  It's one thing
> saying users should look after themselves, but surely it's quite another
> thing to provide an obsure mechanism where one's one keypress away from
> destroying ones system.
>
> I'm quite a bit less enthusiastic about Gentoo than I was a few days
> ago.
>
>> -- 
>> Neil Bothwick
>> Caution, an incorrigible punster - don't incorrige.


The point is the same as it always has been.  If you install a package
outside of portage's knowledge, it is on you to make sure any
dependencies are installed and to update the package itself.  Surely you
don't expect emerge/portage to know you installed a package outside its
knowledge and to keep things it depends on by some sort of magic.  When
a user updates using emerge/portage, it can only go by what it knows. 
It can't assume something it has no knowledge of. 

This is why I mentioned creating a ebuild for your mail program and
using emerge to install it.  In the ebuild will be what that software
depends on.  That puts emerge/portage in the know that certain things
are needed and not to remove them.  Unless you do that, or add needed
packages to the world file, emerge/portage will want to remove things it
feels are not needed based on what it knows.  To be honest, this is
expected behavior.  It's the whole point of --depclean. 

In short, this is expected behavior.  If it didn't work this way, then
I'd say there is a bug that needs to be addressed. 

I might add, this is why I try to never install anything outside of
using emerge/portage.  It always leads to problems like this.  At the
moment, I can think of nothing that is installed on my system that isn't
done by emerge/portage.  Even old software that is dying is still known
to emerge/portage.  When it no longer works, I'll unmerge it and move on
to other software.  At the moment, Gnome-mplayer comes to mind on that. 
Thing is, emerge/portage is aware of every single package installed on
my system. 

At least you have two options that should correct the problem.  Make a
ebuild or add the needed packages for your mail program to the world
file.  Either way should make things work. I'd think the ebuild is the
best way but one has to write the ebuild.  Adding the needed packages to
world file is easiest but could change if you upgrade the mail program. 

Hope you find one of those a good option.

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Neil Bothwick]

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

On Sun, 25 Jul 2021 11:47:40 +0000, Alan Mackenzie wrote:

> > > I would say all packages in @system _are_ needed, unless the user
> > > explicitly says otherwise.  
> 
> > They are, @system is a set of packages and nothing it it will be
> > depcleaned. However, openrc is not part of @system, the virtual is.  
> 
> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.

openrc is not necessarily critical, just some sort of service manager.
that's the whole point of a virtual, to handle different use cases and
requirements.

> > That is possible, but it is also possible that this is entirely down
> > to you installing things outside of portage and handling their
> > dependencies manually, creating unwanted side-effects like this.  
> 
> Quite the contrary.  If I'd've stuck to the daemontools I installed from
> a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
> switched to using the portage version that this danger reared its ugly
> head.

My point is that you are mixing portage and non-portage packages, that's
why portage is getting confused. I don't know much about daemontools, but
it seems the sort of package that should not be in @world, but only
installed as a dependency of something else.

I'm nit suggesting that you should avoid non-portage packages, that may
be impossible or undesirable, but you should be aware of possible
consequences. When I need portage to install dependencies to a
non-portage package, I generally create a set for them, so you could
create qmail-deps containing both daemontools and openrc and emerge it.
Then you are safe from either being depcleaned. If you ever decide to
stop using qmail, you can just unmerge the set and let portage clean up.

> > > Maybe the answer is to regard --depclean as a tool for experts only,
> > > since it is capable in ordinary innocent use of rendering a system
> > > unusable.  
> 
> > I feel it's more a case of Gentoo being a system for those that
> > understand what they are doing with the system - with great power
> > comes great responsibility and all that.  
> 
> That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
> will take the same attitude.  Not only can the user shoot himself in the
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a
> "press here" direction on the packaging above a hidden trigger.  Nobody
> accepts any responsibility for preventing accidents.

It wasn't meant to be patronising, but you should be aware of what is
going on. In this case you were because although portage suggested
removing openrc, you sensibly declined the offer.
 
> The implication of what you say is that nobody should use portage
> without understanding every last intricate detail of it.  This doesn't
> feel reasonable.

No, but it is a system that demands a greater level of understanding from
its users than, say, apt or rpm.

> Nobody but me seems to see anything wrong with all this.  It's one thing
> saying users should look after themselves, but surely it's quite another
> thing to provide an obsure mechanism where one's one keypress away from
> destroying ones system.

You could cripple it but not destroy it. It would not be nice, but you
can recover from the accidental removal of openrc or even python.
Fortunately, you don't have to find out exactly how not nice :)


-- 
Neil Bothwick

- How many surrealists does it take to change a light bulb?
- Two: one to hold the giraffe, the other to fill the bathtub with
  lots of brightly colored machine tools.

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

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Neil Bothwick wrote:
>
> My point is that you are mixing portage and non-portage packages, that's
> why portage is getting confused. I don't know much about daemontools, but
> it seems the sort of package that should not be in @world, but only
> installed as a dependency of something else.
>
> I'm nit suggesting that you should avoid non-portage packages, that may
> be impossible or undesirable, but you should be aware of possible
> consequences. When I need portage to install dependencies to a
> non-portage package, I generally create a set for them, so you could
> create qmail-deps containing both daemontools and openrc and emerge it.
> Then you are safe from either being depcleaned. If you ever decide to
> stop using qmail, you can just unmerge the set and let portage clean up.
>
>

I forgot about the sets option.  That would be another good way to solve
this issue.  It does mean emerge/portage doesn't know why the packages
are needed but it wouldn't remove them because the user told
emerge/portage not too.  That may be better than adding daemontools to
the world file and much easier than creating a ebuild. 

Nice thinking Neil.  :-D 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
>
> I'm considering submitting a bug to bugs.gentoo.org, requesting that
> _all_ installed packages satisfying a virtual get kept.  There is surely
> something wrong when somebody who just wants to be a user (me) has to
> read .ebuild files to get normal things done.
>
>

If you can, I'd recommend trying to reach out to the maintainer to see
if that is expected behavior.  It could be that that is the way it is
supposed to work.  If that is so tho, I find it odd.  Maybe qmail needs
a USE flag to pull in daemontools?  Maybe something else needs
changing.  I'd start by reaching out to the maintainer.  I guess a bug
report would be considered reaching out but a email may also work as well. 

Just my thoughts.  May not be worth much.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie]

Hello, Dale.

On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote:
> Alan Mackenzie wrote:

> > I'm considering submitting a bug to bugs.gentoo.org, requesting that
> > _all_ installed packages satisfying a virtual get kept.  There is surely
> > something wrong when somebody who just wants to be a user (me) has to
> > read .ebuild files to get normal things done.



> If you can, I'd recommend trying to reach out to the maintainer to see
> if that is expected behavior.  It could be that that is the way it is
> supposed to work.  If that is so tho, I find it odd.

I find it infuriating when ordinary innocent use of something like
emerge can totally break a system.

> Maybe qmail needs a USE flag to pull in daemontools?

I'm actually using s/qmail, tarball direct from its maintainer, since
there's no ebuild for it.  Originally, I had daemontools from the same
place, until I discovered there was an ebuild for it.

> Maybe something else needs changing.  I'd start by reaching out to the
> maintainer.  I guess a bug report would be considered reaching out but
> a email may also work as well. 

Thanks, I submitted a bug report.  I think it's a bug in emerge.  I've
got a nasty feeling there isn't enough sympathy for non-experts for that
bug to go anywhere, but we'll see.

> Just my thoughts.  May not be worth much.  ;-)

> Dale

> :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Dale]

Alan Mackenzie wrote:
> Hello, Dale.
>
> On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote:
>
>> Maybe qmail needs a USE flag to pull in daemontools?
> I'm actually using s/qmail, tarball direct from its maintainer, since
> there's no ebuild for it.  Originally, I had daemontools from the same
> place, until I discovered there was an ebuild for it.
>
>

Ahhh.  That could be a issue when filing a bug.  When using something
without the package manager installing it, it usually leaves you on your
own.  The easiest thing may be to just add daemontools to your world
file and leave it at that.  The maintainer may have another solution but
I'm suspecting not. 

Another option, create a ebuild for your mail program and put it in your
overlay.  Then you can use emerge to install your mail program so that
emerge knows the dependencies it needs, including daemontools.  As it
is, it doesn't even know you have the mail program there.  Sort of hard
for emerge/portage to know you need a tool kept around.  A ebuild for it
and using emerge to install it would fix that.  Maybe a USE flag or just
a plain hard requirement for daemontools. 

Just a thought.  Someone else may have a better hammer to fix this
problem. 

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Wols Lists]

On 24/07/21 22:09, Alan Mackenzie wrote:
> I'm actually using s/qmail, tarball direct from its maintainer, since
> there's no ebuild for it.  Originally, I had daemontools from the same
> place, until I discovered there was an ebuild for it.

THAT LOOKS LIKE YOUR PROBLEM.

If daemontools has been pulled in because it's explicitly named in
world, then emerge will (quite reasonably) assume that openrc (which is
an implied dependency) can be dispensed with.

In other words, if one member of a virtual package is explicitly
installed, all the other members can be dispensed with. Changing this is
likely to cause breakage all over the place!!!

Okay, it's a nasty surprise to discover that installing a package with
multiple uses can make the system assume you're using it for things
you're not, but I think the only *workable* fix is, as others have said,
to add openrc to the world set.

You've explicitly pulled in a boot manager package. You can't expect
portage to keep a bunch of implicit package managers (systemd, sysV,
openrc etc) lying around when you haven't asked for them. I've installed
postfix as my mailer - I don't want exim, sendmail, etc etc lying around
"just in case".

Cheers,
Wol