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