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