1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
list what's horked, note your name by it if you want dibs.
This will be updated as things progress; if in doubt/questions about a section, look at the intro doc,
and ask in #gentoo-portage on freenode, or email the portage ml.
Right now, majority of discussion/questions are via irc, although ml will be used a bit more heavily as things start to
flesh out (need to get a solid kernel/core)
**important**
portage.package.cpv.ver_cmp fails on this;
dev-lang/icc-7.1.029 > dev-lang/icc-7.1.006 # thinks .006 is gt .029
[namespace fixes required, plus potentially a bit of rewrite]
:portage.sync:
:portage.transports:
transports needs to be unified behind fetcher design.
need a fetchable class also.
[sort of started, some code avail. at least.]
:portage.vdb.*:
Initial code for at least querying the repo is implemented, but nothing further. Need a package type created for it.
Where it gets a bit hairy (and consult jason/harring if you want to try this portion) is that it is a *modifiable* repo,
packages *do* get added to it. as such, it will need to generate a mergeoperation, something not defined.
Should be designed such that the underlying disk layout is easily changable, since a global contents db for it *will* be
added (thus removing the reliance on mtime + md5 for discerning whether to remove a file).
:portage.binpkg:
bind it to portage.ebuild where ever possible; akin to portage.vdb.*, initial code was scratched out, but no package
instance defined for it; which would be wise/useful.
Keep an eye on the design of it so that remote binpkg (BINHOST) can be easily derived from it.
[not started]
:portage.config.domain:
consult intro doc if you attempt it, and collect feedback from jason/brian regarding it please
harring will want it one way which probably slightly conflicts with what jason wants (and vice versa),
so be aware it's probably going to be a shifting class definition.
still need a prototype though.
:portage.*.fetchable:
find a place for this. simple one however, see intro doc.
:portage.*.(merge|build)operation:
no base class defined yet, see intro.
Not so simple. :)
:emerge:
the UI code (display, etc) can probably be held onto but will need to be refactored to work with the new code.
:repoman:
same thing. might be able to just update it, but a full rewrite (with modular checks) is a *good* thing.
Man how it's raining out...
|
GitWeb
