Hello, Eli. On Sat, Oct 26, 2024 at 21:53:15 -0400, Eli Schwartz wrote: > 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. Software should guard against stupid inputs. > 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). I've already made specific suggestions on this list, and they have not, in general, been well enough received to make the extra effort of submitting bugs worthwhile. For example, I suggested that emerge shouldn't remove @system packages without a specific request or confirmation from the user. > >> 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. As a user, as opposed to a gentoo maintainer, that distinction is meaningless. If gentoo breaks my system, I will be upset and angry regardless of such fine distinctions. It's looking like virtual/service-manager is finally getting fixed (thanks for the prodding!). But the same thing, system critical components being removed by --depclean, might well happen again, since emerge isn't being amended to prevent it. > 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... It looks like they have, now. :-) > > 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. 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". 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. > 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. It seems that we are in violent agreement on this, as well as on masking the wayland user flag. > 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"... .... and we also agree that --depclean is not perfect. ;-) > >> 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 wasn't, no. I am now. > 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. > """ As mentioned above, that is an obscure subsidiary paragraph, inaccessible to somebody who is scanning the man page looking for what they want, as opposed to somebody who is explicitly interested in everything about --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. > 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. OK. > It does sound like an interesting idea though -- maybe worth submitting > a feature request? Maybe. Thanks for all the helpful information over the last month or so. I've learnt a lot. > -- > Eli Schwartz -- Alan Mackenzie (Nuremberg, Germany).
