Normally, I use a regular rsync tree, and on top of that, I have an overlay with various stuff, including symlinks from my CVS tree. With version 2.0.5x, I was able to go into the symlinked directories in the overlay and operate portage commands such as ebuild digest or repoman and portage would be smart enough to know it should refer to the cvs tree.. Portage 2.1 seems confused, sometimes it tries to refer to the overlay and sometimes to the CVS tree.. When doing an ebuild digest I got: getfetchlist aux_get() error reading x11-misc/googleearth-4_beta ... So I copied the files into my overlay instead of symlinking them, that fixed it.. But then repoman wouldn't run because it wasnt run from a full tree, so I had to move them back to my cvs tree..
I'm not sure that this particular case is worth supporting. Wouldn't it make sense to copy the directory from your cvs tree to overlay, rather than symlink it? Note that the behavior has been changed in order to support the case where the root path of the overlay contains one or more symlinks (bug 109961).
well the current behavior is broken because ebuild digest didnt work at all with the symlinked directory and there is no reason for that.
Well, there's a reason for everything. My feeling is that this use case is less common than the other, so I'd rather not revert the changes. This case can certainly be fixed with a little work...
I'll try to have a look at the code to see if I can fix it.
Reopen if you have something
