| 1 |
On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: |
| 2 |
> On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring <ferringb@g.o> |
| 3 |
> wrote: |
| 4 |
> | A) would like to hear what you think is required planning wise |
| 5 |
> | compared to the previous haubi prototype patch. |
| 6 |
> |
| 7 |
> There has been no serious discussion on how *ebuilds* will use the |
| 8 |
> prefix system. Hacking econf and expecting PREFIX to be sufficient is |
| 9 |
> naive from a tree-perspective. |
| 10 |
|
| 11 |
econf isn't the only change required; the point is that whatever is |
| 12 |
decided, would have to be added to econf thus covering a good chunk of |
| 13 |
ebuilds in the tree that don't require fancy voodoo. |
| 14 |
|
| 15 |
The basic proposal of haubi's glep (ignoring the portage innard |
| 16 |
modifications) came down to addition of a prefix var, that would be |
| 17 |
required slipped in for any fs installation paths (--prefix=$PREFX |
| 18 |
fex). |
| 19 |
|
| 20 |
Beyond that, there is the shebang issue which can be addresses via a |
| 21 |
combination of automated scans/fixes, and fixing bugs as it's hit. |
| 22 |
Hardcoded vars in scripts for the path to a binary are an issue also, |
| 23 |
although again, scans can be done to at least check for it. |
| 24 |
|
| 25 |
Leaves mangling the build process so that the build framework of the |
| 26 |
package uses the prefix offset files, rather then / . For c/c++ |
| 27 |
source, usual trick from fink afaik involves a mangling of cflags with |
| 28 |
-I tacked in. Kinda ugly, although I'd expect there is a better |
| 29 |
route. |
| 30 |
|
| 31 |
Packages that pull include/compile settings/args from a utility |
| 32 |
(thinking python configuration tools, and pkgconfig) shouldn't be too |
| 33 |
horrid to change, since it's a matter of modifying it in one place |
| 34 |
(theoretically :). |
| 35 |
~harring |
Archives