Summary: | portage bintree should allow symlinks to packages | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Florian Eitel <gentoobugs> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Florian Eitel
2013-09-10 20:52:17 UTC
The lstat usage is for handling the older $PKGDIR layout which had all the tbz2 files in a $PKGDIR/All subdirectory, and had symlinks in the same place as the tbz2 files in the current layout. Supporting symlinks like yours raises the question of what should happen when binary packages need to be updated for package moves. Would you want portage to replace your symlink with a modified copy of the original tbz2 file, or would this interfere with your setup? In case you aren't familiar with package moves, see here: http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html#moving-ebuilds Ok, I see your point. But in my opinion moving the symlink is the only thing which makes sense. A symlink stays a symlink. Portage doesn't touches the target of the symlink. But the symlink itselfs is moved to a new location but still points to the right location. Until now found some problems in the following files: * portage/emaint/modules/binhost/binhost.py * portage/dbapi/bintree.py * gentoolkit/eclean/search.py (In reply to Florian Eitel from comment #2) > Ok, I see your point. But in my opinion moving the symlink is the only thing > which makes sense. A symlink stays a symlink. Portage doesn't touches the > target of the symlink. But the symlink itselfs is moved to a new location > but still points to the right location. Current versions of portage expect the internal CATEGORY, PF, and ebuild name to be consistent with the package move. Also, the internal metadata has to be modified when the dependencies of the package need to be updated for package moves. Note that the existing code should work fine if you replace your symlinks with hardlinks. Ok, this is a bigger problem than expected. 1.) The current state is: Treat all symlinks as invalid data. 2.) My expectation is, if portage accesses/modifies the file *content* then the target of the symlink gets changed. But all operations (delete, move) on the file itself should only modify the symlink. I think this is a intuitive approach used in most programs. 3.) Another way (which fits my requirement even better): If a file content changes than the symlink is replaced with a new file. The target is not touched. For all operations on the file itselfs the target stays untouched. But of course it is only my view. So, what is the decision? For me the third way is the safest way. Because all the access code can stay as is and the target gets not modified at all. So only the lstat statements gets replaced with stat - the rest stays as is. (bintree.py handles moves in a way that the content is copied and deleted - not moved) But I see a change can lead to trouble because it is more complicated than expected. If you decide to change it, of course I'm willing to help & test. |