Summary: | sys-apps/portage: emerge checks too many files for package collisions 'nodoc/noinfo' FEATURE is enabled | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Marc Burkhardt <marc> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Marc Burkhardt
2010-10-21 16:54:18 UTC
The same actually aplies for the 'noinfo' FEATURE The collision check is before pkg_preinst, and the no{doc,info,man} code runs after pkg_preinst. So, the count displayed in the message is accurate at the time that it's run. If that's not good enough then I suppose we could just remove the count entirely since it's non-essential. Yes, that's correct. What I meant to say is: why do we check the 5 files when only 2 of the files will be installed? It would be enough to check the remaining 2 files _after_ the nodoc/noinfo stuff is run. So we could move the collision check after the nodoc/noinfo stuff and anything is great... The collision check has to go before pkg_preinst, since pkg_preinst is not supposed to execute when we bail out due to collisions. I suppose the no{doc,info,man} code could run before pkg_preinst too. (In reply to comment #4) > I suppose the no{doc,info,man} code could run before pkg_preinst too. However, this makes it easier for ebuild developers to commit ebuilds which have file collisions that are hidden by local features settings. So, I think it's better to simply omit the file count from the collision checking message. (In reply to comment #4) > I suppose the no{doc,info,man} code could run before pkg_preinst too. > That's great! :) What we have then is: * Removing /usr/share/info * Removing /usr/share/doc * Checking 2 files for package collisions or even cooler: * Removing /usr/share/info * Removing /usr/share/doc * Checking 2 of initially 5 files for package collisions You missed comment #5. (In reply to comment #7) > You missed comment #5. > I didn't get the point there ... what use-case do you mean? If an ebuild developer happens to have FEATURES=no{doc,info,man}, it's useful for file collisions to be detected with these files anyway. However, I guess this is hopeless since if they have these features enabled then there won't be any installed files to trigger the collisions. (In reply to comment #9) > If an ebuild developer happens to have FEATURES=no{doc,info,man}, it's useful > for file collisions to be detected with these files anyway. However, I guess > this is hopeless since if they have these features enabled then there won't be > any installed files to trigger the collisions. > Not only that. If an ebuild developer has these FEATUREs set, it is more than bad, isn't it? So ... I guess one could implement it as in comment #6 (I like the 'even cooler' approach best!) |