Re: [gentoo-portage-dev] Questions about CVS locations and GID...

[m h]

Thanks for the warning Alec.  Since I already have very limited
knowledge of the internals, I figure this will be a good trial by fire
(learn sort of the portage internals and issues with prefixed
installs).  If it works, perhaps I will be able to devote more time to
it and do more than a simple prototype (which might involve writing a
spec, talking to Fink people and seeing how they resolved these sorts
of issues and all that fun stuff).  Right now, I'm not very qualified
to write a spec, but I figure when I get my hands into it I'll start
seeing a lot more of the issues one is bound to run into.  If it's so
hard that's it's impossible then maybe I should just give up now....
What sort of "plan" do you suggest?

On 10/5/05, Alec Warner <warnera6@×××××××.edu> wrote:
> Brian Harring wrote:
>
> >On Wed, Oct 05, 2005 at 11:31:32PM +0100, Ciaran McCreesh wrote:
> >
> >
> >>On Wed, 5 Oct 2005 16:13:06 -0500 Brian Harring <ferringb@g.o>
> >>wrote:
> >>| A) would like to hear what you think is required planning wise
> >>| compared to the previous haubi prototype patch.
> >>
> >>There has been no serious discussion on how *ebuilds* will use the
> >>prefix system. Hacking econf and expecting PREFIX to be sufficient is
> >>naive from a tree-perspective.
> >>
> >>
> >
> >econf isn't the only change required; the point is that whatever is
> >decided, would have to be added to econf thus covering a good chunk of
> >ebuilds in the tree that don't require fancy voodoo.
> >
> >The basic proposal of haubi's glep (ignoring the portage innard
> >modifications) came down to addition of a prefix var, that would be
> >required slipped in for any fs installation paths (--prefix=$PREFX
> >fex).
> >
> >Beyond that, there is the shebang issue which can be addresses via a
> >combination of automated scans/fixes, and fixing bugs as it's hit.
> >Hardcoded vars in scripts for the path to a binary are an issue also,
> >although again, scans can be done to at least check for it.
> >
> >Leaves mangling the build process so that the build framework of the
> >package uses the prefix offset files, rather then / .  For c/c++
> >source, usual trick from fink afaik involves a mangling of cflags with
> >-I tacked in.  Kinda ugly, although I'd expect there is a better
> >route.
> >
> >Packages that pull include/compile settings/args from a utility
> >(thinking python configuration tools, and pkgconfig) shouldn't be too
> >horrid to change, since it's a matter of modifying it in one place
> >(theoretically :).
> >~harring
> >
> >
> >
> >
> I guess in the end trying to do something like this is a difficult
> process.  I am wary of anyone who wants to just jump into an application
> like portage and just magically write in this kind of support.  In the
> end one could just try and go step by step, but nothing guarantee's you
> won't miss something, or because it works with packages x,y,z that it
> will work for all packages.
>
> If you have two weeks to do it in, I wish you the best of luck.  Maybe
> you are good enough at learning portage internals to get it done, but
> even after portage support is done there are still plenty of other factors.
>
> In the end I side with Ciaran on this one.  You need to know all the
> bases to cover here in order to make this work well.  Going ahead with
> no plan is stupid IMHO.
> --
> gentoo-portage-dev@g.o mailing list
>
>

-- 
gentoo-portage-dev@g.o mailing list