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