Everytime I run `emerge --depclean`, it uninstalls sys-devel/automake-1.13.4, but omits any other version of automake. At least almost every `emerge -uDN world` reinstalls automake-1.13.4 as a dependency again. Meanwhile this gets pretty annoying and is unnecessarily time-consuming and resource-wasting. So there should be done something that automake-1.13.4 doesn't always get removed by `emerge --depclean`. That said, none of the other automake versions are in my world file. So adding automake-1.13.4 to the world file would only be a very dirty workaround. Reproducible: Always
(In reply to Heiko Baums from comment #0) > So adding automake-1.13.4 to the world file would only be a very dirty > workaround. No, that's the exact purpose of the world file. If nothing needs automake at run time and it is not in your world file, then --depclean should remove it. That is the exact purpose of --depclean. If other versions of automake are kept, then apparently something depends on them. If not, then this would be a bug in sys-apps/portage, or some packages have an unneeded run-time dependency on sys-devel/automake-[VERSION]. Please check that.
(In reply to Jeroen Roovers from comment #1) > No, that's the exact purpose of the world file. > > If nothing needs automake at run time and it is not in your world file, then > --depclean should remove it. That is the exact purpose of --depclean. Generally you are right with this. But I think there is an exception for automake, because it is needed for at least almost every compilation and installation. So for automake this doesn't make much sense. Why is gcc not removed by --depclean? It's also only used at build time, not at runtime. I guess you would get a lot of angry bug reports, if people would have to spend hours for rebuilding gcc everytime they need to install a package or do a world update. > If other versions of automake are kept, then apparently something depends on > them. If not, then this would be a bug in sys-apps/portage, or some packages > have an unneeded run-time dependency on sys-devel/automake-[VERSION]. Please > check that. I will check that, but if this is the case then I wouldn't see this as a bug in this case. In my opinion automake belongs to the core system like gcc does. It was something different if it was only needed every now and then.
(In reply to Jeroen Roovers from comment #1) > If other versions of automake are kept, then apparently something depends on > them. If not, then this would be a bug in sys-apps/portage, or some packages > have an unneeded run-time dependency on sys-devel/automake-[VERSION]. Please > check that. Ok, checked that with at least some packages. None of the ebuilds that depend on any version of automake has automake in its DEPEND or RDEPEND. But all of them have "inherit autotools". The difference between those ebuilds that depend on automake-1.13.4 and the ebuilds that depend on the other automake versions is that the ebuilds that depend on automake-1.13.4 are missing this line: WANT_AUTOMAKE="<none or version>" The other ebuilds that depend on the other automake versions have either WANT_AUTOMAKE="none" or WANT_AUTOMAKE="<version number>" That said, I don't know if this is the reason why automake-1.13.4 is always removed by --depclean, and the other automake versions are not. But since most of the packages depend on automake-1.13.4, I would think it's a bug in those ebuilds or somewhere else in portage.
(In reply to Heiko Baums from comment #2) > (In reply to Jeroen Roovers from comment #1) > > No, that's the exact purpose of the world file. > > > > If nothing needs automake at run time and it is not in your world file, then > > --depclean should remove it. That is the exact purpose of --depclean. > > Generally you are right with this. But I think there is an exception for > automake, because it is needed for at least almost every compilation and > installation. So for automake this doesn't make much sense. You can read `man emerge` about --depclean and --with-bdeps if you want to change this behavior. > Why is gcc not removed by --depclean? It's also only used at build time, not > at runtime. > > I guess you would get a lot of angry bug reports, if people would have to > spend hours for rebuilding gcc everytime they need to install a package or > do a world update. Try removing it, @system requires sys-devel/gcc and thus is kept. > > If other versions of automake are kept, then apparently something depends on > > them. If not, then this would be a bug in sys-apps/portage, or some packages > > have an unneeded run-time dependency on sys-devel/automake-[VERSION]. Please > > check that. > > I will check that, but if this is the case then I wouldn't see this as a bug > in this case. > > In my opinion automake belongs to the core system like gcc does. It was > something different if it was only needed every now and then. That would still remove individuals versions; and adding individual versions to @system, that sounds problematic (stable vs testing tree, etc...); the way we use bdeps now suffices, it is controllable by the user and while some users want to keep them other users would rather like to see them go.
(In reply to Tom Wijsman (TomWij) from comment #4) > That would still remove individuals versions; and adding individual versions > to @system, that sounds problematic (stable vs testing tree, etc...); the > way we use bdeps now suffices, it is controllable by the user and while some > users want to keep them other users would rather like to see them go. But then why haven't the other versions of automake been removed by --depclean? Btw., I just realized that automake-1.13.4 doesn't get removed by --depclean anymore. I don't know if it's because I meanwhile had to run --with-bdeps several times. On the other hand I had to run --with-bdeps before, too.
