Summary: | app-portage/portage-utils-0.4 qfile -o reports nonorphaned symlinks as orphaned | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Marcin Mirosław <bug> |
Component: | Tools | Assignee: | Portage Utils Team <portage-utils> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | armin76 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Marcin Mirosław
2010-07-22 08:39:50 UTC
Is this a regression from 0.3.1? No, the same situation exists in version 0.3.1. the alternatives.eclass takes care of managing the lemon symlink, but it does it in the pkg_* phases and thus no package actually owns it If this is not problem in qfile so this is bug in portage, because portage doesn't track symlinks created by self :) it isnt a bug in portage either. the alternatives.eclass modifies files in $ROOT during the pkg_* step. nothing portage can do to monitor that. |