Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 489768

Summary: emerge --depclean shouldn't remove sys-devel/automake-1.13.4
Product: Gentoo Linux Reporter: Heiko Baums <heiko>
Component: [OLD] Core systemAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: RESOLVED TEST-REQUEST    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Heiko Baums 2013-10-29 13:36:36 UTC
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
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-30 16:53:26 UTC
(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.
Comment 2 Heiko Baums 2013-10-30 17:29:58 UTC
(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.
Comment 3 Heiko Baums 2013-10-30 17:55:46 UTC
(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.
Comment 4 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-02-02 00:19:33 UTC
(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.
Comment 5 Heiko Baums 2014-02-02 00:54:09 UTC
(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.