1 |
Hola all. |
2 |
|
3 |
Straight to the point, I'm proposing that the following files- |
4 |
arch.list |
5 |
categories |
6 |
use.desc |
7 |
use.local.desc |
8 |
package.mask |
9 |
updates |
10 |
|
11 |
be moved out of the profiles directory in the tree, and into the existing |
12 |
metadata directory personally, due to the fact that the files above are |
13 |
essentially repository metadata. Why move them *now* when they've |
14 |
been around forever? |
15 |
|
16 |
Those files should never have been placed there. They're repository |
17 |
specific data (global data for the repo), and do not belong jammed |
18 |
into profiles which is a seperate entity. |
19 |
|
20 |
Further, while no one has yet proposed anything concrete, people have |
21 |
been after revamping the profile implementation. Quite likely if/when |
22 |
this occurs, it's going to require a seperate directory to avoid any |
23 |
issues with older portage installations accessing it. |
24 |
Shifting the files now while changes are being made addresses that |
25 |
concern, and makes things a bit more logical. |
26 |
|
27 |
Not surprising, few issues (and ways to deal with it). |
28 |
For backwards compatability with portage tools, symlinks are needed to |
29 |
prevent older portage versions and tools from suddenly being broke; |
30 |
just do a relative link to the new location, no complaints from |
31 |
portage. CVS does not play nice with symlinks however- fortunately |
32 |
rsync sucks a bit less, so the symlinks would have to be added |
33 |
by the rsync regen script (minor to do). |
34 |
|
35 |
Two scenarios for how this will result in visible issues for people- |
36 |
1) CVS users, aka, devs. Devs *should* be running latest portage, |
37 |
which would know about the shift. If they're running an older |
38 |
portage version and aren't willing to upgrade, they tag the |
39 |
symlinks themselves. It's a minor annoyance frankly; assuming they |
40 |
read -dev (like they're suppossed to :P ), they'll know in advance |
41 |
it's coming. |
42 |
2) users storing their tree on an fs that lacks symlink support. They |
43 |
ought to be a miniscule minority, but any issues they hit would be |
44 |
addressed by upgrading portage and any portage tools they use that |
45 |
is reliant on those files. This is the worst case user scenario, |
46 |
but again, it should be effectively non-existant. |
47 |
|
48 |
Finally, lang.desc I can't find any reference to in portage tools- |
49 |
zhen commited it almost 3 years back, and it hasn't been touched |
50 |
since. Unless somebody knows what the heck that file is for, it's a |
51 |
good candidate for removal. |
52 |
|
53 |
I realize this may seem like a minor/stupid change, but it's a matter |
54 |
of cleanup getting things a bit more consistant for when portage is |
55 |
capable of dealing with more then one $PORTDIR. |
56 |
~harring |