Alan Mackenzie <a...@muc.de> writes: > Hello, Eli. > > On Mon, Sep 23, 2024 at 18:54:50 -0400, Eli Schwartz wrote: >> On 9/23/24 6:08 PM, Alan Mackenzie wrote: >> >> Do you have that little faith in the Gentoo Developers, that you think >> >> we'd make a USE flag change that made everyone's systems suddenly break? > >> > It happens, from time to time, by accident. For example, emerge >> > --depclean on my system wants to unmerge openrc. Not a deliberate >> > move by the developers, just some accident. But it's the reason I >> > don't do emerge --depclean, ever. > >> 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. > > [ .... ] > >> So, @system requires you to have any one of: > >> - openrc >> - openrc-navi (a testing fork with openrc user services) >> - s6 >> - systemd >> - runit >> - daemontools > >> 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.
In that case, it'd be wise to 'emerge -n openrc' to prevent such trouble. I do wonder if we should keep s6, runit and daemontools in that virutal though, given that we can't boot them. Perhaps they'd be fine behind a USE flag. I'll propose that. >> 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. > >> 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. Whoever closed it was wrong, frankly. > There are several ways this could have been fixed, for example with > --depclean preserving packages in system, as well as world. That probably would not fix anything here, openrc is not in @system, virtual/service-manager is. > 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. Developers differ a good bit.. we generally try not to break things. > 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. -- Arsen Arsenović
signature.asc
Description: PGP signature
