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 |