Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] The future of einstall
Date: Sat, 30 Aug 2014 20:55:01
Message-Id: 20140830225439.533a522b@pomiot.lan
1 Developers,
3 I believe that we should work towards deprecating and removing
4 the einstall helper from PMS, for the following reasons:
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.
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.
17 Why do we have einstall?
18 ------------------------
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.
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.
30 If anyone could shed some more light into this, I'd appreciate that.
33 What is so bad about einstall?
34 ------------------------------
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.
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.
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.
55 What should we do?
56 ------------------
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).
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'.
68 What do you think?
71 [1]:
72 [2]:
74 --
75 Best regards,
76 Michał Górny


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] The future of einstall Ulrich Mueller <ulm@g.o>