| 1 |
Developers, |
| 2 |
|
| 3 |
I believe that we should work towards deprecating and removing |
| 4 |
the einstall helper from PMS, for the following reasons: |
| 5 |
|
| 6 |
1. einstall is confusing to new developers and contributors who often |
| 7 |
see it as the 'proper' way of installing software -- mostly because of |
| 8 |
the name matching econf/emake/einstall scheme. Likely that scheme was |
| 9 |
desired in the past. |
| 10 |
|
| 11 |
2. The use for it is pretty scarce. Major build systems and most of |
| 12 |
the common custom Makefiles support DESTDIR. For the few remaining |
| 13 |
cases, it's rather optimistic throwing of variables into make, |
| 14 |
and hoping they would work. |
| 15 |
|
| 16 |
|
| 17 |
Why do we have einstall? |
| 18 |
------------------------ |
| 19 |
|
| 20 |
I don't know the exact reasoning for having it in the first place. |
| 21 |
One reason I've heard is that old versions of automake didn't support |
| 22 |
DESTDIR, and therefore we had to specify all the directories. However, |
| 23 |
DESTDIR support in automake dates back to 1998 when automake 1.3 was |
| 24 |
released -- and that pretty much predates Gentoo. |
| 25 |
|
| 26 |
I've asked Ciaran about it, and he said that 'the idea was to avoid |
| 27 |
people duplicating anything'. In other words, that einstall was used |
| 28 |
only because calling 'emake install DESTDIR="${D}"' was considered bad. |
| 29 |
|
| 30 |
If anyone could shed some more light into this, I'd appreciate that. |
| 31 |
|
| 32 |
|
| 33 |
What is so bad about einstall? |
| 34 |
------------------------------ |
| 35 |
|
| 36 |
As I mentioned before, it's thoroughly confusing for contributors, |
| 37 |
and a few Gentoo developers too. From my little research done lately, |
| 38 |
I've discovered about 80 packages that were using einstall though their |
| 39 |
build system clearly indicated support for DESTDIR [2]. While the list |
| 40 |
may still have a few false positives, it indicates how often einstall |
| 41 |
is used mistakenly. |
| 42 |
|
| 43 |
For a comparison, there is less than 40 packages using einstall that |
| 44 |
didn't make it to that list. Most of them involve custom build systems |
| 45 |
that actually do not require passing all the overrides einstall does -- |
| 46 |
sometimes plain 'emake install DESTDIR=${D} PREFIX=/usr' or alike would |
| 47 |
be enough. |
| 48 |
|
| 49 |
In other words, there's more than twice as much confusion due to it |
| 50 |
than real use of it. Even then, the use is not strictly correct. |
| 51 |
And lastly, it involves rather corner cases, and I believe PMS should |
| 52 |
focus on supporting the common cases. |
| 53 |
|
| 54 |
|
| 55 |
What should we do? |
| 56 |
------------------ |
| 57 |
|
| 58 |
As I see it, we should simply ban einstall in EAPI 6. This way, we can |
| 59 |
prevent further mistakes from happening and let developers fix |
| 60 |
the current consumers once bumping EAPI (or lastrite them at some |
| 61 |
point). |
| 62 |
|
| 63 |
If it becomes really necessary, we can move the function into |
| 64 |
an eclass. However, I'd rather not do it unless there is a real gain |
| 65 |
from having it there. Custom build systems should be likely handled |
| 66 |
with dedicated install phases rather than an 'one size fits all'. |
| 67 |
|
| 68 |
What do you think? |
| 69 |
|
| 70 |
|
| 71 |
[1]:http://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html#other-installs |
| 72 |
[2]:https://bugs.gentoo.org/show_bug.cgi?id=521420 |
| 73 |
|
| 74 |
-- |
| 75 |
Best regards, |
| 76 |
Michał Górny |
Archives