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


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

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


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



-- 
Eli Schwartz

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to