Gentoo Archives: gentoo-dev

From: "Bruce A. Locke" <blocke@××××××.org>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] prefix overide portage
Date: Wed, 20 Feb 2002 03:55:17
Message-Id: 1014198836.5069.3.camel@kodiak.chronospace.org
In Reply to: Re: [gentoo-dev] prefix overide portage by Dave Lee
1 On Tue, 2002-02-19 at 23:38, Dave Lee wrote:
2
3 > I don't think this would actually be "hacking", I would call it something
4 > much nicer, like cleaning up.
5
6 Hacking as in trying to "hack around in" an autogenerated script that
7 quite frankly wasn't meant for humans to edit it, or having to
8 autogenerate our own configure scripts using a system few people really
9 understand :)
10
11 I do think "hacking" is the correct term here ;)
12
13 > I can see the desire to set a custom
14 > install prefix, and I think that making the ebuild scripts more flexible
15 > to allow for this may prove useful in that it will make the portage system
16 > much more flexible and customizable. It should't be too much effort to
17 > let loose some scripts on the portage tree to fix --preifx=/usr to
18 > --preifx=$SOME_PREFIX_VAR where the SOME_PREFIX_VAR can be set in
19 > /etc/make.conf. In another thread Vitaly Kushneriuk said "the Gentoo way
20 > is to provide user with the maximum control that is practical" and I dont
21 > think having a custom prefix would be impractical. Anyway, just my
22 > thoughts on the subject. One thing to note is that I noticed the ebuild
23 > system is "rigid" like this in more ways than just preifx, every other
24 > configure variable is hardcoded by the ebuild author into the ebuild file,
25 > like mandir and others. In rpm systems, when you create an rpm spec, you
26 > can use %{_prefix} and %{_mandir} when you build rpms, and that gives it
27 > some flexibility.
28
29 Agreed, it would be a nice addition. It would help if someone
30 associated with portage would add relavent support to portage or at
31 least set an example as a standard. This means we could make sure all
32 new packages follow it and we can phase it into older packages over time
33 as we update them for other reasons.
34
35 --
36
37 Bruce A. Locke
38 blocke@××××××.org