On 10/25/24 3:22 PM, Alan Mackenzie wrote: >> 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.
I would argue the precise opposite, that the job of emerge is to faithfully do what you tell it to do and the job of ::gentoo is to not tell emerge to do stupid things. We should fix bugs, not break tools by assuming bugs won't be fixed. Especially when no clear proposal about how emerge should be changed exists (ideally in the form of a detailed feature request on the Portage bugtracker). >> 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. "we" have established no such thing. You claim that --depclean can break one's system, I disputed this notion and claim that virtual/service-manager can break one's system. You may argue all you want -- I cannot provide any guarantees about whether other people will agree with you that the problem is portage, but I'm always open to hearing persuasive arguments. On that note I am happy that there was reasonable discussion on the bug report at https://bugs.gentoo.org/803878 but also somewhat disappointed that despite what seems like a lot of support for making the proposed fix, no one has actually stepped up and made that fix yet... > 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. I find this wording confusing and difficult to understand on your part. There is no option to unmerge specific packages only, using "--unmerge". I just tried it: ``` # emerge --unmerge emerge unmerge can only be used with specific package names ``` Oops? Your claims are totally invalid. I am nitpicking about this for an extremely good reason. Since --unmerge requires you to *specify the package name* (and since you have used it a lot, you surely know this fact) I don't think it should come as a shock that ``` # emerge --depclean CAT/MYPKG ``` also works. And, lo and behold -- it is a version of --unmerge that unmerges specific packages only, which does safety checks first. This is also how I use --depclean by the way. I generally never depclean all packages, I take a look at what "emerge --depclean --pretend" suggests can be depcleaned and then decide whether I want to selectively depclean some of them by name. I will say that I wish --depclean accepted glob patterns which would then match only on packages which are eligible for default-depcleaning. I have a small awk script that processes the output of "emerge -cpq" to select packages that aren't required by @world which match specific patterns such as language-specific categories for libraries, so e.g. I can depclean "all dev-perl stuff unless another package needs it"... >> 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. ... again, it literally says to use --depclean, but I'm increasingly getting the feeling that you are not *aware* that --depclean accepts package names. I find this odd, since the manpage entry for --depclean says it pretty clearly: """ Depclean serves as a dependency aware version of --unmerge. When given one or more atoms, it will unmerge matched packages that have no reverse dependencies. """ > --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. Implementing a per-package ask seems like it would be challenging, as it would have to go back and recalculate which packages can still be asked about if you respond "no" to some package that other packages depend on. It does sound like an interesting idea though -- maybe worth submitting a feature request? -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
