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

[Eli Schwartz <eschwartz@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2318 bytes --]

On 10/27/24 6:52 PM, Alan Mackenzie wrote:
> OK, thanks.  I didn't know that.  The emerge man page section for
> --depclean is far from clear on the point.  Looking at it more closely,
> it doesn't mention giving it arguments until the very last subsidiary
> paragraph.  It could, for example, start with "WITHOUT ARGUMENTS, cleans
> the system by removing packages that are ....".  And it could replace
> that useless weasel phrase "associated with" with "dependencies of".


I see what you mean. The --depclean flag (and --unmerge as well) is
listed in the section for "action"s. depclean isn't an *option* such as
--ask / --color / --jobs / --verbose / etc.

And, the synopsis states that all *actions* allow specifying optional
atoms / sets / etc at the same time.

This isn't clear from reading the individual documentation on an action,
but I'm not sure what a solution here might look like.


> It could also warn users that their system packages are not protected
> against removal in certain circumstances.
> 
> It could correct the error where it says "Packages that are part of the
> world set will always be kept.".  Earlier on on the man page it defines
> @world to be the amalgam of @selected, @system, and @profile.  Despite
> the reassuring words, --depclean wants to delete nano and openrc (still),
> which are part of @world.


@world is an alias expansion (it expands its contents, in this case,
@selected @system @profile).

@system is also an alias expansion -- it expands the profile-based list
of atoms for system.

Moving beyond that, nano and openrc aren't an *expansion* of @world, but
they are an RDEPEND of atoms (virtual/*) that are expanded from @world.

The emerge documentation says that packages that are part of the world
set -- i.e. they are expanded from @world -- will be kept. It doesn't
say that their dependencies will be kept (there are arguments about why
this is the portage design, but this discussion is less about whys and
more about whether the documentation is correct, so that's what I will
address).

I don't really see that part of the documentation as being in error.
Although I suppose I also don't see any harm in rewording it for
additional clarity. I'm not sure exactly how to reword it...


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]