Recently I had a little IRC bikeshed with bonsaikitten on the topic of .la file removal. As one of the maintainers of autotools-utils.eclass, I tend to like people actually using that eclass and keeping the .la removal algorithm there; bonsaikitten would like to see it in Portage instead.
To prove my point, let’s take a look at the process of making a change in an eclass:
- getting eclass maintainers’ approval,
- sending patches to gentoo-dev for review,
- …
- PROFIT!
The whole process usually takes one week, and the change is effective as soon as user syncs the tree. This means that if the particular change aims to fix an issue with an ebuild yet to be committed, its commit can be delayed. And considering it is committed after eclass change, users won’t even notice the breakage.
Although getting a change in a single PM can usually be faster, it starts being effective when user upgrades it. This usually means that the ebuild author has either to work around the problem or delay the commit until fix gets stable, and then still a number of users could be hit by the bug.
For PMS, I think the situation is clear. A lot of time to get it into PMS, get new EAPI approved, get it implemented, stabilize and finally get blessing for the tree.
Although this could sound like this, I’m not denying PMS. PMS has its coverage but I really don’t see a reason to put everything into it just for the fun. In my opinion, PMS should cover most fundamental functions which either are very simple (and thus unlikely to introduce bugs) or highly relevant to the PM internals.
For example, emake in Portage reuses MAKEOPTS variable which can be considered private/internal. elog relies on PM-specific output system, and doins… well, one can say it could reuse some magic to optimize the merge process (OTOH, ebuilds already assume it does not).
econf on the other hand, although pretty common, doesn’t fully fit into PMS. The only magic it uses, it uses for libdir; and it is very specific to autoconf. But the same magic needs to be implemented in multilib.eclass to let non-autoconf build systems handle libdir correctly.
Returning to the topic: .la removal is not suitable for either PMS or PM because:
- it is very specific to autotools and libtool,
- it requires either a smart algo or some magic to determine which files to remove and which ones to keep,
- and for those kept, more magic could be required.
A quite sane algo is implemented in autotools-utils right now. When further packages are migrated to it, maintainers can give us feedback on it and help us improve it. And if it fails on a new package, we can commit a fix before the package hits final users.
If Portage started removing .la files on its own, we end up with either:
- having a really smart algo which will always work right, or random breakages for a number of users with solution being ‘upgrade portage and rebuild offending packages’;
- implementing some kind of Portage-specific variables to control the .la removal better.
I really don’t like any of those. So, just migrate your ebuilds! Distutils use distutils.eclass, CMake uses cmake-utils.eclass. There’s no reason to not inherit a dedicated eclass for autotools, with autotools-specific quirks.
Ah, and please finally stop pushing everything into PMS just because some devs break eclass APIs. If someone breaks policy on instance, that person should be punished. Locking all devs in cages is no solution.
Ok, first of all this is a change outside of PMS, so you don’t even have to throw that around.
My suggestion was to add a FEATURE to newer portage that removes all .la files that are not in a whitelist (which could just be KEEP_LA_FILES variable in ebuilds). It won’t timetravel into the past and break stuff, just from that point on they’ll slowly disappear. And the few cases where they are needed can be handled by editing those few ebuilds – whereas your suggestion means editing each and every ebuild to get the new features applied.
Stop keeping yourself busy, start being lazy :)