[gentoo-dev] The future of einstall

[gentoo-dev] The future of einstall

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] The future of einstall

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

>>>>> On Sat, 30 Aug 2014, Michał Górny wrote:

> I believe that we should work towards deprecating and removing
> the einstall helper from PMS, for the following reasons:

> [...]

> 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.

Looks like econf and einstall were added to Portage at the same time,
in January 2002:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild.sh?hideattic=0&revision=1.12&view=markup

The earliest mentioning of einstall that I could find in our mailing
lists is in the following post (interestingly, its subject also starts
with "The future of"):
http://archives.gentoo.org/gentoo-dev/msg_52c0fb35cfe1bb3228f9ec1816bb2aeb.xml

However, "make DESTDIR=${D} install" already existed in
base_src_install in 2001, before einstall was introduced:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/base.eclass?revision=1.1&view=markup#l59

> 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).

It may be worth mentioning that econf in EAPI 6 will pass --docdir
and --htmldir options to configure. These would take precedence over
einstall's prefix="${ED}"/usr, i.e. einstall's path for documentation
files would be broken because ${D} would be missing from it.

So _if_ we decide to keep einstall, then we would have to pass
additional docdir and htmldir variables. OTOH, maybe this would be a
good occasion for getting rid of the function.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] The future of einstall

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

>>>>> On Sun, 31 Aug 2014, Ulrich Mueller wrote:

>>>>> On Sat, 30 Aug 2014, Michał Górny wrote:
>> 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).

> It may be worth mentioning that econf in EAPI 6 will pass --docdir
> and --htmldir options to configure. These would take precedence over
> einstall's prefix="${ED}"/usr, i.e. einstall's path for documentation
> files would be broken because ${D} would be missing from it.

> So _if_ we decide to keep einstall, then we would have to pass
> additional docdir and htmldir variables. OTOH, maybe this would be a
> good occasion for getting rid of the function.

I see no further replies to this thread, so I will raise this as an
item for the next council meeting.

Currently, only 218 ebuilds are using einstall, which is less than
0.6 % of all ebuilds in the tree.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]