The Gentoo handbook (x86 at least) documents that emerge --unmerge is the primary way to remove packages and only offers a short warning that it can be unsafe and to use emerge --depclean instead (and says it will explain later how to do it), however there is no explanation anywhere in the handbook on how to use emerge --depclean to remove a single package. My suggestion is to replace the usage of --unmerge in the "Removing a package" section with --depclean, removing the warnings, and POSSIBLY the addition of a section explaining (in a better way than this, i'm not a good writer) that when there's a big blocker, or a package with false reverse-dependencies or something, then it MAY be useful to use --unmerge. Reproducible: Always
I disagree with hiding it entirely; with Portage 2.2's preserved-libs feature, there's a good chance it won't break anything even if they depend on it. I do this pretty often because I have software that needs both (incompatible) versions of miniupnpc...
(In reply to comment #1) > I disagree with hiding it entirely; with Portage 2.2's preserved-libs feature, Except not everybody uses Portage 2.2. And from a user support standpoint, it's easier to tell one person that --unmerge exists than to walk 50 people through fixing their now broken system because they used --unmerge when --depclean would have saved them.
I don't see why this would even be considered. The emerge --unmerge way is the primary way of removing packages, so there is no errata in that portion of the section. Sure, --depclean can be nice, but you can't unmerge something *now* without updating world first. So, I must upgrade, for example openoffice, libreoffic, kde-meta, or anything else, in order to unmerge something trvial like eject ? Teaching that to a new user still learning the basics from the handbook is teaching them a gentoo experience of waiting ages to do even simple tasks and isn't going to make them happy. Another downside is that it would be inserting another layer between learning users and what is going on. If a user is going to foolishly --unmerge gcc or their libc or something else critical, they same user is going to find a way to force --depclean to do it for them anyway; this wouldn't prevent much harm, it would just acknowledge an expected dumbing down of the target userbase and imply that users can't be trusted to remove packages without a crutch. If --depclean needs to be discussed further, then the discussion should be added, but that would still not render --depclean the primary method of package removal.
(In reply to comment #3) > I don't see why this would even be considered. The emerge --unmerge way is the > primary way of removing packages, so there is no errata in that portion of the > section. > > Sure, --depclean can be nice, but you can't unmerge something *now* without > updating world first. So, I must upgrade, for example openoffice, libreoffic, > kde-meta, or anything else, in order to unmerge something trvial like eject ? > Teaching that to a new user still learning the basics from the handbook is > teaching them a gentoo experience of waiting ages to do even simple tasks and > isn't going to make them happy. > > Another downside is that it would be inserting another layer between learning > users and what is going on. If a user is going to foolishly --unmerge gcc or > their libc or something else critical, they same user is going to find a way to > force --depclean to do it for them anyway; this wouldn't prevent much harm, it > would just acknowledge an expected dumbing down of the target userbase and > imply that users can't be trusted to remove packages without a crutch. > > If --depclean needs to be discussed further, then the discussion should be > added, but that would still not render --depclean the primary method of package > removal. yup. stays as-is for the time being.
(In reply to comment #3) > I don't see why this would even be considered. The emerge --unmerge way is the > primary way of removing packages, so there is no errata in that portion of the > section. Nobody should be using --unmerge as it may break installed packages dependencies. It should only be used in situations where you have to break them to get around some other problem. > > Sure, --depclean can be nice, but you can't unmerge something *now* without > updating world first. So, I must upgrade, for example openoffice, libreoffic, > kde-meta, or anything else, in order to unmerge something trvial like eject ? > Teaching that to a new user still learning the basics from the handbook is > teaching them a gentoo experience of waiting ages to do even simple tasks and > isn't going to make them happy. It's not true that you have to update everything. The handbook is wrong there too. What is true is that you need to not have unsatisfied dependencies for your installed packages. Incidentally exactly these unsatisfied dependencies are created by --unmerge. > > Another downside is that it would be inserting another layer between learning > users and what is going on. If a user is going to foolishly --unmerge gcc or > their libc or something else critical, they same user is going to find a way to > force --depclean to do it for them anyway; this wouldn't prevent much harm, it > would just acknowledge an expected dumbing down of the target userbase and > imply that users can't be trusted to remove packages without a crutch. > Does that mean that you look at the entire dependency tree of @world before you remove a package with --unmerge? I don't think users would assume that I think they are dump if I don't expect that from them. > If --depclean needs to be discussed further, then the discussion should be > added, but that would still not render --depclean the primary method of package > removal. (In reply to comment #4) [...] > > yup. stays as-is for the time being. What's the reason for this decision?
