On 9/24/24 7:30 AM, Alan Mackenzie wrote:
>> This should not generally be possible. The @system set contains
>> virtual/service-manager, so you cannot depclean that.
> 
> It is very much possible, and it happens.  The mechanism is understood,
> you've outlined it below.


Clearly, since I said it is "generally" not possible, I agree that it is
sometimes possible and the mechanism for the sometimes is understood.

After all, I did outline it, and you agree with my outline.

So why, exactly, are you *arguing* with me, as though you believe I have
said it is not possible?

Can you point me to where I said it is not possible?

I said it's an edge case, not a systematic flaw in Gentoo or portage
designed to break people's systems. Edge cases should be reported and
fixed, but also edge cases have trivial workarounds which you can carry
out: add openrc manually to @world, and it is no longer dangerous to run
--depclean as part of regular maintenance of a healthy system.


>> It's possible you have installed another one of these packages too. If
>> you do, then virtual/service-manager will still be satisfied, and it
>> will allow you to depclean openrc.
> 
> Yes, I have daemontools, needed as a component of a qmail variant.


Sigh, djbware strikes again. The fact that daemontools claims to be a
service manager, but is needed for random packages WITHOUT being used as
a service manager, is alarming and probably broken.


>> In theory, one should not have multiple init systems installed. And
>> openrc is the preferred satisfier, so if you use `emerge --depclean` it
>> will try to depclean the other package, not openrc. But you can depclean
>> openrc itself in that case, since portage doesn't know which init system
>> you intend to keep.
> 
> If I had invoked --depclean without the -a (or -p) flag, my system would
> have had openrc removed, and it would have been unbootable.  This is the
> sort of thing a new Gentoo user might do.
> 
>> Even in this case it emits a warning:
> 
>> !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system
>> profile.
>> !!! Unmerging it may be damaging to your system.
> 
> So, having your system made unbootable is opt-out rather than opt-in.


That is a severely unkind interpretation of what I said, and of what
portage does.

Also, installing daemontools isn't the kind of thing a new Gentoo user
might do. Nor is installing qmail.


>> to make sure you are fully aware that you intend to depclean a package
>> that *might* be the wrong one.
> 
> The context of this discussion was an implication that the Gentoo
> maintainers wouldn't make a change "that made everyone's systems suddenly
> break".  I submitted a bug report about --depclean back in the summer of
> 2021 (though I can't find that bug any more).  I think it was closed as
> not-a-bug.
> 
> There are several ways this could have been fixed, for example with
> --depclean preserving packages in system, as well as world.  But it was
> regarded as not a bug.
> 
> So I think it is fair to say that the Gentoo developers are content for
> some systems (in particular, mine) suddenly to break.  I am thus somewhat
> sceptical about things in Gentoo which may be based on assumptions which
> don't hold in my system.  The new +wayland USE flag kind of looked a bit
> like that to me.  Actually, it wasn't, so I apologise for my opening
> post.


There is nothing sudden about this! No change has been made! According
to your explanation, the presence of daemontools on a system has always
made --depclean result in potentially making a system unbootable.

The Gentoo developers have taken no action to *make* this a problem. It
is the unfortunate combination of a number of moving parts that together
result in a historically present issue.

Inferring from here that Gentoo developers making an active profile
change with the intent of resulting in systems suddenly breaking while
dismissing concerns, is unreasonable, irrational, and paranoid. Sorry.

Gentoo works better when users report issues and ask for them to be fixed.

Gentoo works better when users see a change and ask what the
ramifications are, e.g. "I was curious whether this would have a
negative effect on my X-only system", rather than immediately leaping to
"PSA!!! DANGER ALERT! CODE RED, ALL GENTOO USERS BEWARE!!!"

You can always post the "PSA!!! DANGER ALERT! CODE RED" if you asked for
information and did not get an answer that satisfied you, but the
initial assumption of good faith would be appreciated.


....


Regarding the daemontools situation:

"""
for example with --depclean preserving packages in system, as well as world
"""

Is not a valid suggestion, since --depclean already does precisely this,
but openrc isn't a package in system, it is a package that satisfies a
recursive dependency of system. As far as portage knows, it is already
doing exactly what you want it to do, as described in the Package
Manager Specification.

Perhaps you meant to say that --depclean should preserve all versions of
an "any-of" dependency. This would break a whole lot of use cases, as
then one would no longer be able to change their system to suit
themselves using the intended power of virtuals.

For example, it would become impossible for a user to install s6-rc into
their world file, with the intention of using s6-rc as their service
manager, and then --depclean and remove openrc which they no longer
intend to use!

(It would also be impossible to install vim or emacs, then uninstall
nano. For that matter, it would be impossible for an emacs user to
install vim, try it out for a day, decide they don't like it, and
uninstall vim. Vim would be there to stay: forever.)

Normally, installing s6-rc is an intentional action to use s6-rc. But
apparently, "normally" installing daemontools isn't an intentional
action to use daemontools.

Thus, reporting this as a bug against portage is illogical, but
reporting it as a bug against virtual/service-manager is logical. I can
understand why a bug submitted "about --depclean" would be closed as
not-a-bug, since it is... not, in fact, a bug, there is a totally
different bug.

Perhaps the person who closed that bug should have thought deeper about
the implications of such a thing, and reassigned that bug to the correct
package with a fixed explanation. And perhaps you should have
communicated better why it's a problem for you to install daemontools
*without intending to* and having that affect openrc. For example, by
highlighting that daemontools isn't being used as a service manager and
you do not believe installing "ordinary applications such as qmail"
should be allowed to override your choice of init system.


-- 
Eli Schwartz