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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Tue, Sep 24, 2024 at 15:36:43 -0400, Eli Schwartz wrote:
> On 9/24/24 2:53 PM, Alan Mackenzie wrote:
> >> 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.


> Indeed, you are correct, but I am not sure why you'd need to read the
> spec anyway.

> That is why I am correct too -- since I am pointing out that things like
> requesting specific portage / PMS behavior when interacting with virtual
> packages is not how one should perceive the end-user problem.

> (A virtual package is "just" a package with no installed files. How
> virtual packages are used is a matter of Gentoo policy, not a matter of
> how portage works. And PMS only mentions virtual packages once, and that
> one time is to state that the old way was removed from the spec and that
> new style virtuals are "just packages, and have no special treatment".)

> Since it is "just a package", the solution should lie in fixing
> ::gentoo, not in fixing the "emerge" command. That's what the re-opened
> bug is about. :)

What is getting fixed are the data.  That leaves the same problem in the
emerge code to bite again the next time there are faulty data.

> >> 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.


> Recommending an option that can break your system is a workaround, not a
> solution. Surely we want to end up in a good state of affairs, eventually?

We've already established that --depclean can break one's system, not
just theoretically but in real world use.  --unmerge is surely safer -
you're unmerging specific packages which, presumably, you've already
checked for safety.

There doesn't appear to be anything better in emerge - I've looked but
not found an emerge action to unmerge specific packages only, apart from
--unmerge.  Why is there not a version of --unmerge which does safety
checks first?

The envisaged work flow seems to be doing things like --deselect,
followed by --depclean, praying that the latter isn't going to break the
system.  Given how much safer --unmerge is than --depclean, I don't
understand why the emerge man page puts a bold face warning right at the
start of --unmerge, but not on --depclean.

> The emerge manpage warns you against using --unmerge for good reason.

But doesn't state that reason or give a workable alternative.  Saying it
can remove important packages is unhelpful if it doesn't give an
alternative which can't.

My current workflow for clearing out orphaned packages is to do emerge
-p --depclean, then use emerge --unmerge on those packages listed which
aren't critical system packages or needed application programs.

> >> (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.


> If you want all 3, then virtual/editor isn't an appropriate way to
> install a large collection of apps. Add them to your world file.

virtual/editor is an obscure internal mechanism of portage.  If I emerge
vim, and emerge Emacs, I expect portage to respect my intentions, as
well as not assuming I want rid of nano or anything else in @system.

> virtual/editor doesn't restrict how many editors you have installed, it
> simply requires you have at least one.

> And it shouldn't require that any editors you install, cannot be
> uninstalled with --depclean

--depclean is too clumsy.  It assumes I want to unmerge nano, for reasons
which are surely not intended UI, but just because that's the way it was
implemented.  I think a --ask flag only asks whether to delete all listed
packages or none, not each package individually.  What I would prefer is
an interface by which _I_ specify which packages are to be removed.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).