| 1 |
m h wrote: |
| 2 |
|
| 3 |
>Thanks for the warning Alec. Since I already have very limited |
| 4 |
>knowledge of the internals, I figure this will be a good trial by fire |
| 5 |
>(learn sort of the portage internals and issues with prefixed |
| 6 |
>installs). If it works, perhaps I will be able to devote more time to |
| 7 |
>it and do more than a simple prototype (which might involve writing a |
| 8 |
>spec, talking to Fink people and seeing how they resolved these sorts |
| 9 |
>of issues and all that fun stuff). Right now, I'm not very qualified |
| 10 |
>to write a spec, but I figure when I get my hands into it I'll start |
| 11 |
>seeing a lot more of the issues one is bound to run into. If it's so |
| 12 |
>hard that's it's impossible then maybe I should just give up now.... |
| 13 |
>What sort of "plan" do you suggest? |
| 14 |
> |
| 15 |
>On 10/5/05, Alec Warner <warnera6@×××××××.edu> wrote: |
| 16 |
> |
| 17 |
> |
| 18 |
>>Brian Harring wrote: |
| 19 |
>> |
| 20 |
>> |
| 21 |
>> |
| 22 |
>>>On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote: |
| 23 |
>>> |
| 24 |
>>> |
| 25 |
>>> |
| 26 |
>>> |
| 27 |
>>>>On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring <ferringb@g.o> |
| 28 |
>>>>wrote: |
| 29 |
>>>>| A) would like to hear what you think is required planning wise |
| 30 |
>>>>| compared to the previous haubi prototype patch. |
| 31 |
>>>> |
| 32 |
>>>>There has been no serious discussion on how *ebuilds* will use the |
| 33 |
>>>>prefix system. Hacking econf and expecting PREFIX to be sufficient is |
| 34 |
>>>>naive from a tree-perspective. |
| 35 |
>>>> |
| 36 |
>>>> |
| 37 |
>>>> |
| 38 |
>>>> |
| 39 |
>>>econf isn't the only change required; the point is that whatever is |
| 40 |
>>>decided, would have to be added to econf thus covering a good chunk of |
| 41 |
>>>ebuilds in the tree that don't require fancy voodoo. |
| 42 |
>>> |
| 43 |
>>>The basic proposal of haubi's glep (ignoring the portage innard |
| 44 |
>>>modifications) came down to addition of a prefix var, that would be |
| 45 |
>>>required slipped in for any fs installation paths (--prefix=$PREFX |
| 46 |
>>>fex). |
| 47 |
>>> |
| 48 |
>>>Beyond that, there is the shebang issue which can be addresses via a |
| 49 |
>>>combination of automated scans/fixes, and fixing bugs as it's hit. |
| 50 |
>>>Hardcoded vars in scripts for the path to a binary are an issue also, |
| 51 |
>>>although again, scans can be done to at least check for it. |
| 52 |
>>> |
| 53 |
>>>Leaves mangling the build process so that the build framework of the |
| 54 |
>>>package uses the prefix offset files, rather then / . For c/c++ |
| 55 |
>>>source, usual trick from fink afaik involves a mangling of cflags with |
| 56 |
>>>-I tacked in. Kinda ugly, although I'd expect there is a better |
| 57 |
>>>route. |
| 58 |
>>> |
| 59 |
>>>Packages that pull include/compile settings/args from a utility |
| 60 |
>>>(thinking python configuration tools, and pkgconfig) shouldn't be too |
| 61 |
>>>horrid to change, since it's a matter of modifying it in one place |
| 62 |
>>>(theoretically :). |
| 63 |
>>>~harring |
| 64 |
>>> |
| 65 |
>>> |
| 66 |
>>> |
| 67 |
>>> |
| 68 |
>>> |
| 69 |
>>> |
| 70 |
>>I guess in the end trying to do something like this is a difficult |
| 71 |
>>process. I am wary of anyone who wants to just jump into an application |
| 72 |
>>like portage and just magically write in this kind of support. In the |
| 73 |
>>end one could just try and go step by step, but nothing guarantee's you |
| 74 |
>>won't miss something, or because it works with packages x,y,z that it |
| 75 |
>>will work for all packages. |
| 76 |
>> |
| 77 |
>>If you have two weeks to do it in, I wish you the best of luck. Maybe |
| 78 |
>>you are good enough at learning portage internals to get it done, but |
| 79 |
>>even after portage support is done there are still plenty of other factors. |
| 80 |
>> |
| 81 |
>>In the end I side with Ciaran on this one. You need to know all the |
| 82 |
>>bases to cover here in order to make this work well. Going ahead with |
| 83 |
>>no plan is stupid IMHO. |
| 84 |
>>-- |
| 85 |
>>gentoo-portage-dev@g.o mailing list |
| 86 |
>> |
| 87 |
>> |
| 88 |
>> |
| 89 |
>> |
| 90 |
|
| 91 |
My point was not to scare you so much as to make you aware of the |
| 92 |
problems you will face. Most of them are not portage problems. Most of |
| 93 |
the problems are ebuild problems, found in each piece of software that |
| 94 |
will be used in this manner. All of the ebuilds are written for one |
| 95 |
domain, and now they are being used in another. Ciaran has already |
| 96 |
given a few examples of the trouble. In this case "Getting it to work" |
| 97 |
is easy. Getting it to work for all packages = a ton of work. |
| 98 |
|
| 99 |
-Alec |
| 100 |
PS: Nothing I say should stop you, I am by no means an expert. |
| 101 |
PSS: Good Luck. |
| 102 |
-- |
| 103 |
gentoo-portage-dev@g.o mailing list |
Archives