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 |