Gentoo Archives: gentoo-portage-dev

From: m h <sesquile@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Questions about CVS locations and GID...
Date: Wed, 05 Oct 2005 20:48:34
Message-Id: e36b84ee0510051348j10bbad50k7aa785498806cc9@mail.gmail.com
In Reply to: Re: [gentoo-portage-dev] Questions about CVS locations and GID... by Brian Harring
1 On 10/5/05, Brian Harring <ferringb@g.o> wrote:
2 > Yay, time for another flame war (just what I'd love to spend my time
3 > on).
4
5 Sorry, I'm really not trying to kindle any flames here.
6
7 > > >I looked through the dev documentation but couldn't find anywhere
8 > > >where it stated the actual location of the code in CVS. Any pointers
9 > > >would be great.
10 > We've moved to svn, which will be available via viewcvs shortly.
11 > Anonymous svn is available if you poke your head into irc.freenode.net
12 > #gentoo-portage, and pull it from the /topic.
13 >
14
15 thanks for the pointer
16
17 > > >The issue I found is with pym/cache/fs_template.py. If I'm running as
18 > > >root (GID = 0) then this fails:
19 > > >
20 > > > def __init__(self, label, auxdbkeys, basepath=None, gid=-1,
21 > > >perms=0664, **config):
22 > > > """throws InitializationError if needs args aren't
23 > > > specified"""
24 > > > if not gid:
25 > > > raise
26 > > >cache_errors.InitializationError(self.__class__, "must specify gid!")
27 > Judging by location, that's 2.1.
28 >
29 > The extra opts are directly changable via configuration under the
30 > rewrite's code, so setting gid isn't hard.
31 >
32 > > >Shouldn't the logic be "if gid != -1"? I don't have access to a
33 > > >gentoo proper box right now...
34 > Yah.
35 > That said that code's been corrected under the rewrite.
36
37 So, on the topic of rewrite. Does there happen to be any testcases
38 for portage? Unittests, etc? I'd be nice to verify that rewrite
39 behaves properly (well, actually I want testcases for selfish reasons,
40 so I don't break code if I change anything....)
41
42 >
43 > > I thought that part of brian's domain stuff in Savior was to cover this.
44 > > In either case no one should be writing any real code at this point
45 > > since no one has agreed on any sane way to pull this off. There needs
46 > > to be plenty of healthy discussion the pro's and con's of how things
47 > > should be done in regards to *-prefix.
48 >
49 > There was plenty of discussion about it last time around. It got sunk
50 > due to the fact that ciaran was a bit hell bent on having HOME
51 > integrated into it. All or none, was effectively the issue.
52 >
53
54 Yes, I waded through a bit of that discussion... I really don't care
55 about the HOME issue (I'm not saying that others can't ;)). My take
56 is that an app can do what it wants, and if it puts something in HOME
57 so be it. In my case, there usually won't be two versions of an app
58 (so it shouldn't be an issue), though I realize others have differenct
59 use cases, and expectations.
60
61 > The current line of thought on it is global prefix going in as an addition
62 > to an EAPI release, _strictly_ global prefix. The home crap (interdomain
63 > deps, querying information/location of package X) being a later release.
64 >
65
66 Sorry, I don't know what EAPI means....
67
68 > Why? Doing prefix is hard. Doing prefix + home is harder. A global
69 > offset for PREFIX is going to require a fair amount of work. Tacking
70 > home into it (something that a global offset does _not_ require) is
71 > sadling a requested feature with a lesser feature.
72
73 Sounds good to me....
74
75 >
76 > Do 'em seperate. Those who want interdomain, they can do the work.
77 > Those who want global offset, they can do that chunk.
78 >
79
80 I understand the interdomain stuff to be that prefixed packages can
81 depend on packages outside of their prefix? If so, I don't want this
82 "feature". I want an isolated sandbox. (Again, I realize others have
83 different needs)
84
85
86 > To head off the "it's not going to work for vim-*", yah, you'll be
87 > boned and have to install duplicate vim-* into the global prefix.
88 > Bluntly, either you dive in and start wading through the problems
89 > (fixing them as you go), or you sit back listening to how it's never
90 > going to work (thus accomplishing nothing).
91 > ~harring
92 >
93
94 So, I figure I'm sortof diving in with Haubi's code (against the
95 advice of those wanted a complete spec) since I think my needs seem to
96 be the most minimum subset of what others want in this feature. I
97 think it's a good way to help me understand the innards of portage
98 (though the code is pretty spaghetti right now). I presume you think
99 I should start with "rewrite" as a base? What is the current status
100 of rewrite?
101
102 Sorry for all the questions, again I'm not looking to start a flame
103 war, I'm looking for some features and like what gentoo has done and
104 what can be done with it. I'm not trying to work against or outside
105 what the mainline developers are doing....
106
107 --
108 gentoo-portage-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-portage-dev] Questions about CVS locations and GID... Brian Harring <ferringb@g.o>