Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

["Arsen Arsenović" <arsen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3557 bytes --]

Alan Mackenzie <acm@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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]