[gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Ulrich Mueller <ulm@gentoo.org>]

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

>>>>> On Tue, 30 Sep 2014, Rich Freeman wrote:

> The next Gentoo Council meeting is on 14 Oct 2014 at 19:00 UTC.
> The draft agenda is posted and will be updated at:
> http://dev.gentoo.org/~rich0/council/council_agenda_20141014.txt

> If you'd like to contribute another agenda item, please reply to
> this email.

Let's vote on removal of the einstall function in EAPI 6, please.

Discussion reference:
http://thread.gmane.org/gmane.linux.gentoo.devel/92713

Quoting mgorny:

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

Furthermore:
- Addition of --docdir and --htmldir to econf would require extending
  the existing einstall function, i.e. docdir and htmldir would have
  to be passed as additional variables. Otherwise, docdir and htmldir
  from configure would override the prefix passed to make.
- einstall is conceptionally strange. As noted by mgorny in item 2
  above, it assumes on the one hand that the build system doesn't
  support DESTDIR (so must be something other than autotools based).
  On the other hand, it assumes that the Makefile supports variables
  like prefix and libdir (which are autotools variables).
- As of 2014-09-13, only 218 ebuilds were using einstall, which is
  less than 0.6 % of all ebuilds in the tree. Such scarce usage
  doesn't justify a shortcut function in the package manager. It is
  trivial to change the remaining ebuilds to call the expanded "emake
  install" instead (and typically, only a subset of variables will be
  needed).

Ulrich

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