Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 342045 - sys-apps/portage: emerge checks too many files for package collisions 'nodoc/noinfo' FEATURE is enabled
Summary: sys-apps/portage: emerge checks too many files for package collisions 'nodoc/...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High enhancement with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-21 16:54 UTC by Marc Burkhardt
Modified: 2022-10-20 02:44 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Burkhardt 2010-10-21 16:54:18 UTC
- emerge an ebuild using emerge with FEATURES += nodoc enabled
- emerge checks file collisions
- not N but only M files should have been checked due to the files will not be installed anyways

Example (iftop as just one case of actually any package installing something into /usr/share/doc) - the below example has 2 files to be installed, not 5 that have been checked

 * checking 5 files for package collisions
 * Removing /usr/share/info
 * Removing /usr/share/doc
--- /usr/
--- /usr/share/
--- /usr/share/man/
--- /usr/share/man/man8/
>>> /usr/share/man/man8/iftop.8.bz2
--- /usr/sbin/
>>> /usr/sbin/iftop
Comment 1 Marc Burkhardt 2010-10-21 16:57:16 UTC
The same actually aplies for the 'noinfo' FEATURE
Comment 2 Zac Medico gentoo-dev 2010-10-27 18:45:36 UTC
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.
Comment 3 Marc Burkhardt 2010-10-27 18:49:48 UTC
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...
Comment 4 Zac Medico gentoo-dev 2010-10-27 18:59:45 UTC
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.
Comment 5 Zac Medico gentoo-dev 2010-10-27 19:18:49 UTC
(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.
Comment 6 Marc Burkhardt 2010-10-27 19:38:22 UTC
(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

Comment 7 Zac Medico gentoo-dev 2010-10-27 19:53:01 UTC
You missed comment #5.
Comment 8 Marc Burkhardt 2010-10-27 19:55:26 UTC
(In reply to comment #7)
> You missed comment #5.
> 


I didn't get the point there ... what use-case do you mean?
Comment 9 Zac Medico gentoo-dev 2010-10-27 20:30:08 UTC
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.
Comment 10 Marc Burkhardt 2010-10-27 20:36:56 UTC
(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!)