Many Gentoo packages require installation of other packages. Sometimes these requirements change & a previously required package is not long required. When this happens, users need to know, so that they can unmerge the package which is no longer needed in their system. At present, no alert is given by Portage. When a new version of a package is made available, its Gentoo maintainer has to write an amended ebuild, which will no longer list the previously required package in the cases described above. Portage could also detect the change, provided the previous ebuild is still in the tree. This means that it should not be difficult to provide an alert to users in these cases. The simplest way of providing such alerts seems to be for the maintainer to set a flag in the ebuild, telling Portage that a package has been dropped from the list of requirements. Portage would then add a boilerplate message, including the name of the package which has been dropped, in its output to the user. It is true that users can run depclean to find such dropped packages, but they should not have to do this clean-up work perhaps unnecessarily, then it is fairly easy to have Portage advise them when it is in fact necessary. Reproducible: Always Steps to Reproduce: 1. Install a previously installed package which had required packages. 2. Discover, perhaps some time later, that the requirement no longer applies. 3. Remover the now unwanted package. Actual Results: As above Expected Results: Portage should alert users when packages are no long requirements for other packages.
It prints this after every update: * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information.
I don't believe there is any solution to this besides depclean. When one package gets upgraded and a dependency is dropped, you still have to check against all other installed packages to make sure it's safe to remove.
After updates, portage currently prints the following: * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. Following these instructions should safely remove installed packages that are no longer required by any of the packages in the @world set.
(In reply to Ben Kohler from comment #2) > I don't believe there is any solution to this besides depclean. I'ld like to suggest there may be one (smile). > When one package gets upgraded and a dependency is dropped, > you still have to check against all other installed packages > to make sure it's safe to remove. Certainly, but that's easily done via 'emerge -cpv <pkg1>'. What's needed is an alert that <pkg1> is no longer needed for <pkg2> & therefore may not be needed at all, depending on other requirements. When I try 'emerge -cpv' (ie --depclean), I get a long list of errors : Calculating dependencies... done! * Dependencies could not be completely resolved due to * the following required packages not being installed: * * dev-lang/perl:0/5.18=[-build(-)] pulled in by: * dev-perl/Authen-SASL-2.160.0-r1 * * games-misc/games-envd pulled in by: * games-sports/foobillard-3.0a * * dev-lang/perl:0/5.18=[-build(-)] pulled in by: * dev-perl/File-Listing-6.40.0-r1 * [long list of perl pkgs snipped] * dev-lang/perl:0/5.18=[-build(-)] pulled in by: * dev-perl/XML-Simple-2.200.0-r1 * * Have you forgotten to do a complete update prior to depclean? The * most comprehensive command for this purpose is as follows: * * emerge --update --newuse --deep --with-bdeps=y @world Well no, I haven't forgotten anything : perhaps I don't want to update everything in World to the very latest. What I want is simply to be told by the maintainer whenever a previously required pkg is no longer required by a remerged pkg. Since the maintainer must know of the dropped requirement when he rewrites the ebuild, it sb simple for him to alert users. Then I can try 'emerge -cpv <pkg>' to see if I can safely unmerge it.
emerge -cpv pkgname *is* depclean, and it often won't be usable if you aren't fully up to date.
(In reply to Philip Webb from comment #4) > When I try 'emerge -cpv' (ie --depclean), I get a long list of errors : These kinds of issues are caused by --dynamic-deps, and _not_ using --with-bdeps=y when updating. So, you should be able to avoid them entirely if you put --with-bdeps=y and --dynamic-deps=n in EMERGE_DEFAULT_OPTS (you may also need to use --changed-deps when updating, otherwise --dynamic-deps=n may lead to dependency conflicts).
(In reply to Philip Webb from comment #4) > What I want is simply to be told by the maintainer > whenever a previously required pkg is no longer required by a remerged pkg. > Since the maintainer must know of the dropped requirement > when he rewrites the ebuild, it sb simple for him to alert users. > Then I can try 'emerge -cpv <pkg>' to see if I can safely unmerge it. I don't think that's very practical, because there may be a large number of packages to remove. It's much easier to simply do a global --depclean to remove all of the obsolete packages. If you follow my suggestions from comment #6, it should work fine.
(In reply to Zac Medico from comment #7) > (In reply to Philip Webb from comment #4) > > What I want is simply to be told by the maintainer > > whenever a previously required pkg is no longer required by a remerged pkg. > > Since the maintainer must know of the dropped requirement > > when he rewrites the ebuild, it sb simple for him to alert users. > > Then I can try 'emerge -cpv <pkg>' to see if I can safely unmerge it. > I don't think that's very practical, because there may be a large number of > packages to remove. Occasionally, there might be several pkgs which are no longer required, but typically it should be only one or two. What users need to be told is that those pkgs are no longer required for the just-emerged pkg & that they might like to try 'emerge -cpv <pkgs>' to see if it's safe to remove them. > It's much easier to simply do a global --depclean to remove all of the > obsolete packages. If you follow my suggestions from comment #6, it should > work fine. I did try your suggestions & there was not change : I still received a long list of Perl files which caused a blockage. What I'm suggesting should not be difficult to implement & would improve users' ability to manage the pkgs which they have installed.
(In reply to Philip Webb from comment #8) > I did try your suggestions & there was not change : I still received a long > list of Perl files which caused a blockage. I'm fairly certain that you did not do it correctly, because if you have successfully executed the following command then you should not have any problem running --depclean: emerge --update --newuse --deep --with-bdeps=y @world I've been doing this for years and I never have any problems.
I think it's safe to say that we developers (and indeed the users who've commented in this thread) find this too impractical to be useful. Feel free to submit a more nuanced (or entirely different) suggestion as a different bug. Thanks for contributing discussion to the emerge UI!
