[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] The future of einstall
From:       Ulrich Mueller <ulm () gentoo ! org>
Date:       2014-08-31 12:19:11
Message-ID: 21507.4799.533828.529914 () a1i15 ! kph ! uni-mainz ! de
[Download RAW message or body]


> > > > > 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 #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]