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

[Brian Harring <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

Yay, time for another flame war (just what I'd love to spend my time 
on).

On Wed, Oct 05, 2005 at 04:06:47PM -0400, Alec Joseph Warner wrote:
> >Hey Folks-
> >
> >I'm working on trying to get prefixed installs working.  (As such, I'm
> >using some code kindly modified by Michael Haubenwallner. )  I'm now
> >in python code (portage) and would like to compare what I have with
> >gentoo proper.
> >Is this the location of the latest up to date portage code (in CVS, I
> >realized devs might have more "up to date" code on their boxes):
> >http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/?root=gentoo-src
>
> >I looked through the dev documentation but couldn't find anywhere
> >where it stated the actual location of the code in CVS.  Any pointers
> >would be great.
We've moved to svn, which will be available via viewcvs shortly.  
Anonymous svn is available if you poke your head into irc.freenode.net 
#gentoo-portage, and pull it from the /topic.

> >The issue I found is with pym/cache/fs_template.py.  If I'm running as
> >root (GID = 0) then this fails:
> >
> >        def __init__(self, label, auxdbkeys, basepath=None, gid=-1,
> >perms=0664, **config):
> >               """throws InitializationError if needs args aren't 
> >               specified"""
> >               if not gid:
> >                       raise
> >cache_errors.InitializationError(self.__class__, "must specify gid!")
Judging by location, that's 2.1.

The extra opts are directly changable via configuration under the 
rewrite's code, so setting gid isn't hard.

> >Shouldn't the logic be "if gid != -1"?  I don't have access to a
> >gentoo proper box right now...
Yah. 
That said that code's been corrected under the rewrite.

> I thought that part of brian's domain stuff in Savior was to cover this. 
>  In either case no one should be writing any real code at this point 
> since no one has agreed on any sane way to pull this off.  There needs 
> to be plenty of healthy discussion the pro's and con's of how things 
> should be done in regards to *-prefix.

There was plenty of discussion about it last time around.  It got sunk 
due to the fact that ciaran was a bit hell bent on having HOME 
integrated into it.  All or none, was effectively the issue.

The current line of thought on it is global prefix going in as an addition 
to an EAPI release, _strictly_ global prefix.  The home crap (interdomain 
deps, querying information/location of package X) being a later release.

Why?  Doing prefix is hard.  Doing prefix + home is harder.  A global 
offset for PREFIX is going to require a fair amount of work.  Tacking 
home into it (something that a global offset does _not_ require) is 
sadling a requested feature with a lesser feature.

Do 'em seperate.  Those who want interdomain, they can do the work.  
Those who want global offset, they can do that chunk.

To head off the "it's not going to work for vim-*", yah, you'll be 
boned and have to install duplicate vim-* into the global prefix.
Bluntly, either you dive in and start wading through the problems 
(fixing them as you go), or you sit back listening to how it's never 
going to work (thus accomplishing nothing).
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]