| 1 |
On Wed, Oct 05, 2005 at 01:48:03PM -0700, m h wrote: |
| 2 |
> On 10/5/05, Brian Harring <ferringb@g.o> wrote: |
| 3 |
> > Yay, time for another flame war (just what I'd love to spend my time |
| 4 |
> > on). |
| 5 |
> |
| 6 |
> Sorry, I'm really not trying to kindle any flames here. |
| 7 |
Heh, you're not, I'm just mildly pissy due to recurrent flamewars :) |
| 8 |
|
| 9 |
> So, on the topic of rewrite. Does there happen to be any testcases |
| 10 |
> for portage? Unittests, etc? I'd be nice to verify that rewrite |
| 11 |
> behaves properly (well, actually I want testcases for selfish reasons, |
| 12 |
> so I don't break code if I change anything....) |
| 13 |
Niadda. |
| 14 |
|
| 15 |
Would love it if someone stepped up on that, since I don't |
| 16 |
particularly have the time right now :) |
| 17 |
|
| 18 |
|
| 19 |
> > The current line of thought on it is global prefix going in as an addition |
| 20 |
> > to an EAPI release, _strictly_ global prefix. The home crap (interdomain |
| 21 |
> > deps, querying information/location of package X) being a later release. |
| 22 |
> > |
| 23 |
> |
| 24 |
> Sorry, I don't know what EAPI means.... |
| 25 |
Ebuild API. |
| 26 |
Stable portage's ebuild env, funcs available, etc, is EAPI=0. |
| 27 |
|
| 28 |
Think of it as specifying the lib you want; the ebuild.sh specific |
| 29 |
changes that will be in the rewrite (elib, src_configure phase |
| 30 |
addition, deprived setup phase) would be EAPI=1 |
| 31 |
|
| 32 |
Basically, it gives us a way to introduce changes for how ebuilds are |
| 33 |
called/executed, what they expect from the env, without breaking |
| 34 |
things. It also gives us a way to break compatibility between EAPI |
| 35 |
versions; as long as the metadata exported is correct for the ebuild's |
| 36 |
EAPI and we're still doing a declarative design for calling into the |
| 37 |
ebuild, we can basically do whatever we want. |
| 38 |
|
| 39 |
> > Do 'em seperate. Those who want interdomain, they can do the work. |
| 40 |
> > Those who want global offset, they can do that chunk. |
| 41 |
> |
| 42 |
> I understand the interdomain stuff to be that prefixed packages can |
| 43 |
> depend on packages outside of their prefix? If so, I don't want this |
| 44 |
> "feature". I want an isolated sandbox. (Again, I realize others have |
| 45 |
> different needs) |
| 46 |
Pretty much. Best description is dependencies between root's. |
| 47 |
Global prefix (for osx) would either |
| 48 |
A) have a vdb for that prefix that represented the package.provided |
| 49 |
nodes |
| 50 |
B) have a domain for root=/, and do interdomain. |
| 51 |
|
| 52 |
A is likely route due to it being a helluva lot simpler; B is |
| 53 |
better/cleaner (imo), but it requires more work. |
| 54 |
|
| 55 |
Baby steps. :) |
| 56 |
|
| 57 |
> > To head off the "it's not going to work for vim-*", yah, you'll be |
| 58 |
> > boned and have to install duplicate vim-* into the global prefix. |
| 59 |
> > Bluntly, either you dive in and start wading through the problems |
| 60 |
> > (fixing them as you go), or you sit back listening to how it's never |
| 61 |
> > going to work (thus accomplishing nothing). |
| 62 |
> > ~harring |
| 63 |
> > |
| 64 |
> |
| 65 |
> So, I figure I'm sortof diving in with Haubi's code (against the |
| 66 |
> advice of those wanted a complete spec) since I think my needs seem to |
| 67 |
> be the most minimum subset of what others want in this feature. I |
| 68 |
> think it's a good way to help me understand the innards of portage |
| 69 |
> (though the code is pretty spaghetti right now). I presume you think |
| 70 |
> I should start with "rewrite" as a base? What is the current status |
| 71 |
> of rewrite? |
| 72 |
Rewrite's code is a heck of a lot cleaner; oop based for starters :) |
| 73 |
There is some nastyness, but it's encapsulated, and pretty much |
| 74 |
required. |
| 75 |
|
| 76 |
Current state of it is that I'm atm stuck on plugin code, and a slight |
| 77 |
change to the config handling code. |
| 78 |
|
| 79 |
Building/fetching are done, full immutable ebuild tree and vdb are |
| 80 |
done, immutable binpkg repository is done sans a package class. |
| 81 |
|
| 82 |
The mutable thing is basically querying the db; for vdb and binpkg, |
| 83 |
they need to be modifiable, able to add a package to the repository |
| 84 |
(merging). I'm working on that atm. |
| 85 |
|
| 86 |
Jason's doing resolver work, state of that I can't comment on (that's |
| 87 |
his thing). |
| 88 |
|
| 89 |
ebuild*sh side of it's already done- if you were looking to test out |
| 90 |
prefix building (experiment) I'd probably start there. |
| 91 |
|
| 92 |
|
| 93 |
> Sorry for all the questions, again I'm not looking to start a flame |
| 94 |
> war, I'm looking for some features and like what gentoo has done and |
| 95 |
> what can be done with it. I'm not trying to work against or outside |
| 96 |
> what the mainline developers are doing.... |
| 97 |
|
| 98 |
Wouldn't worry about it, my initial response was phrased strongly due |
| 99 |
to the fact whenever implementing global prefix is brought up the |
| 100 |
screams against it start prior to even being able to iron out, or |
| 101 |
discuss it. |
| 102 |
|
| 103 |
~harring |
Archives