Hello, Eli. On Tue, Sep 24, 2024 at 11:15:10 -0400, Eli Schwartz wrote: > On 9/24/24 7:30 AM, Alan Mackenzie wrote:
[ .... ] > >> 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. Yes, we agree on this. > >> 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. I don't think somebody whose system would no longer boot would agree with you there. > Also, installing daemontools isn't the kind of thing a new Gentoo user > might do. Nor is installing qmail. I don't see why not. I was new to Gentoo (but knew qmail) when I first installed it on Gentoo. > >> 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. Please note that when I raised the matter, I first described it as accidental, and I've never meant to imply it was anything else. The "content for some systems ... to break" was a direct reference to bug 803878 being summarily rejected in 2021. Anyhow, I think all misunderstandings with respect to that bug have now been resolved, and it is getting fixed. > Gentoo works better when users report issues and ask for them to be fixed. As I did with bug 803878. > 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!!!" Perhaps. As already said, I would have been much less jumpy if the explanations which have come in this thread had been in a news item. With this change involving wayland, users HAVE to make a decision, namely whether to set USE='-wayland', as both of us have done, or to accept the bloat of around 50 packages and many megabytes of things like qt and kde libraries. I think the necessary background information to make that decision was missing. > 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. I think that's a rather obscure distinction. Do users actually perceive virtual packages this way? I certainly don't. > As far as portage knows, it is already doing exactly what you want it > to do, as described in the Package Manager Specification. My machine would have become unbootable long before I got around to reading that spec. > Perhaps you meant to say that --depclean should preserve all versions of > an "any-of" dependency. Yes, that's what I meant - at least those in @system. > 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. What is wrong with # emerge --unmerge? I fail to see why that isn't entirely satisfactory. > 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! # emerge --unmerge openrc. > (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.) What about the users, who can't be all that rare, who wish all of nano, vim, and emacs to be installed? They're application programs, not system services. > 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. Yes. > 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 -- Alan Mackenzie (Nuremberg, Germany).
