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
OpenPGP_signature.asc
Description: OpenPGP digital signature
