Developers, I believe that we should work towards deprecating and removing the einstall helper from PMS, for the following reasons:
1. einstall is confusing to new developers and contributors who often
see it as the 'proper' way of installing software -- mostly because of
the name matching econf/emake/einstall scheme. Likely that scheme was
desired in the past.
2. The use for it is pretty scarce. Major build systems and most of
the common custom Makefiles support DESTDIR. For the few remaining
cases, it's rather optimistic throwing of variables into make,
and hoping they would work.
Why do we have einstall?
------------------------
I don't know the exact reasoning for having it in the first place.
One reason I've heard is that old versions of automake didn't support
DESTDIR, and therefore we had to specify all the directories. However,
DESTDIR support in automake dates back to 1998 when automake 1.3 was
released -- and that pretty much predates Gentoo.
I've asked Ciaran about it, and he said that 'the idea was to avoid
people duplicating anything'. In other words, that einstall was used
only because calling 'emake install DESTDIR="${D}"' was considered bad.
If anyone could shed some more light into this, I'd appreciate that.
What is so bad about einstall?
------------------------------
As I mentioned before, it's thoroughly confusing for contributors,
and a few Gentoo developers too. From my little research done lately,
I've discovered about 80 packages that were using einstall though their
build system clearly indicated support for DESTDIR [2]. While the list
may still have a few false positives, it indicates how often einstall
is used mistakenly.
For a comparison, there is less than 40 packages using einstall that
didn't make it to that list. Most of them involve custom build systems
that actually do not require passing all the overrides einstall does --
sometimes plain 'emake install DESTDIR=${D} PREFIX=/usr' or alike would
be enough.
In other words, there's more than twice as much confusion due to it
than real use of it. Even then, the use is not strictly correct.
And lastly, it involves rather corner cases, and I believe PMS should
focus on supporting the common cases.
What should we do?
------------------
As I see it, we should simply ban einstall in EAPI 6. This way, we can
prevent further mistakes from happening and let developers fix
the current consumers once bumping EAPI (or lastrite them at some
point).
If it becomes really necessary, we can move the function into
an eclass. However, I'd rather not do it unless there is a real gain
from having it there. Custom build systems should be likely handled
with dedicated install phases rather than an 'one size fits all'.
What do you think?
[1]:http://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html#other-installs
[2]:https://bugs.gentoo.org/show_bug.cgi?id=521420
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
