| 1 |
Yay, time for another flame war (just what I'd love to spend my time |
| 2 |
on). |
| 3 |
|
| 4 |
On Wed, Oct 05, 2005 at 04:06:47PM -0400, Alec Joseph Warner wrote: |
| 5 |
> >Hey Folks- |
| 6 |
> > |
| 7 |
> >I'm working on trying to get prefixed installs working. (As such, I'm |
| 8 |
> >using some code kindly modified by Michael Haubenwallner. ) I'm now |
| 9 |
> >in python code (portage) and would like to compare what I have with |
| 10 |
> >gentoo proper. |
| 11 |
> >Is this the location of the latest up to date portage code (in CVS, I |
| 12 |
> >realized devs might have more "up to date" code on their boxes): |
| 13 |
> >http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src |
| 14 |
> |
| 15 |
> >I looked through the dev documentation but couldn't find anywhere |
| 16 |
> >where it stated the actual location of the code in CVS. Any pointers |
| 17 |
> >would be great. |
| 18 |
We've moved to svn, which will be available via viewcvs shortly. |
| 19 |
Anonymous svn is available if you poke your head into irc.freenode.net |
| 20 |
#gentoo-portage, and pull it from the /topic. |
| 21 |
|
| 22 |
> >The issue I found is with pym/cache/fs_template.py. If I'm running as |
| 23 |
> >root (GID = 0) then this fails: |
| 24 |
> > |
| 25 |
> > def __init__(self, label, auxdbkeys, basepath=None, gid=-1, |
| 26 |
> >perms=0664, **config): |
| 27 |
> > """throws InitializationError if needs args aren't |
| 28 |
> > specified""" |
| 29 |
> > if not gid: |
| 30 |
> > raise |
| 31 |
> >cache_errors.InitializationError(self.__class__, "must specify gid!") |
| 32 |
Judging by location, that's 2.1. |
| 33 |
|
| 34 |
The extra opts are directly changable via configuration under the |
| 35 |
rewrite's code, so setting gid isn't hard. |
| 36 |
|
| 37 |
> >Shouldn't the logic be "if gid != -1"? I don't have access to a |
| 38 |
> >gentoo proper box right now... |
| 39 |
Yah. |
| 40 |
That said that code's been corrected under the rewrite. |
| 41 |
|
| 42 |
> I thought that part of brian's domain stuff in Savior was to cover this. |
| 43 |
> In either case no one should be writing any real code at this point |
| 44 |
> since no one has agreed on any sane way to pull this off. There needs |
| 45 |
> to be plenty of healthy discussion the pro's and con's of how things |
| 46 |
> should be done in regards to *-prefix. |
| 47 |
|
| 48 |
There was plenty of discussion about it last time around. It got sunk |
| 49 |
due to the fact that ciaran was a bit hell bent on having HOME |
| 50 |
integrated into it. All or none, was effectively the issue. |
| 51 |
|
| 52 |
The current line of thought on it is global prefix going in as an addition |
| 53 |
to an EAPI release, _strictly_ global prefix. The home crap (interdomain |
| 54 |
deps, querying information/location of package X) being a later release. |
| 55 |
|
| 56 |
Why? Doing prefix is hard. Doing prefix + home is harder. A global |
| 57 |
offset for PREFIX is going to require a fair amount of work. Tacking |
| 58 |
home into it (something that a global offset does _not_ require) is |
| 59 |
sadling a requested feature with a lesser feature. |
| 60 |
|
| 61 |
Do 'em seperate. Those who want interdomain, they can do the work. |
| 62 |
Those who want global offset, they can do that chunk. |
| 63 |
|
| 64 |
To head off the "it's not going to work for vim-*", yah, you'll be |
| 65 |
boned and have to install duplicate vim-* into the global prefix. |
| 66 |
Bluntly, either you dive in and start wading through the problems |
| 67 |
(fixing them as you go), or you sit back listening to how it's never |
| 68 |
going to work (thus accomplishing nothing). |
| 69 |
~harring |
Archives