Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Cc: gentoo-portage-dev@l.g.o
Subject: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
Date: Sat, 27 Aug 2005 08:47:07
Message-Id: 20050827084225.GW1701@nightcrawler
Hola all.

Straight to the point, I'm proposing that the following files-

be moved out of the profiles directory in the tree, and into the existing 
metadata directory personally, due to the fact that the files above are 
essentially repository metadata.  Why move them *now* when they've 
been around forever?

Those files should never have been placed there.  They're repository 
specific data (global data for the repo), and do not belong jammed 
into profiles which is a seperate entity.

Further, while no one has yet proposed anything concrete, people have 
been after revamping the profile implementation.  Quite likely if/when 
this occurs, it's going to require a seperate directory to avoid any 
issues with older portage installations accessing it.  
Shifting the files now while changes are being made addresses that 
concern, and makes things a bit more logical.

Not surprising, few issues (and ways to deal with it).
For backwards compatability with portage tools, symlinks are needed to 
prevent older portage versions and tools from suddenly being broke; 
just do a relative link to the new location, no complaints from 
portage.  CVS does not play nice with symlinks however- fortunately  
rsync sucks a bit less, so the symlinks would have to be added 
by the rsync regen script (minor to do).

Two scenarios for how this will result in visible issues for people- 
1) CVS users, aka, devs.  Devs *should* be running latest portage, 
   which would know about the shift.  If they're running an older 
   portage version and aren't willing to upgrade, they tag the 
   symlinks themselves.  It's a minor annoyance frankly; assuming they 
   read -dev (like they're suppossed to :P ), they'll know in advance 
   it's coming.
2) users storing their tree on an fs that lacks symlink support.  They 
   ought to be a miniscule minority, but any issues they hit would be 
   addressed by upgrading portage and any portage tools they use that 
   is reliant on those files.  This is the worst case user scenario, 
   but again, it should be effectively non-existant.

Finally, lang.desc I can't find any reference to in portage tools- 
zhen commited it almost 3 years back, and it hasn't been touched 
since.  Unless somebody knows what the heck that file is for, it's a 
good candidate for removal.

I realize this may seem like a minor/stupid change, but it's a matter 
of cleanup getting things a bit more consistant for when portage is 
capable of dealing with more then one $PORTDIR.