| Summary: | sys-apps/portage-2.1.11.9: elog is used for useless "Directory symlink(s) may need protection" messages | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Pacho Ramos <pacho> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 484436 | ||
|
Description
Pacho Ramos
2012-07-25 20:36:26 UTC
I don't think the message should be triggered very often anyway. The reasons that I made it an elog message are: 1) The search is time consuming, so the log message is there to notify people in case they wonder what's consuming the time. By using elog, it they'll see the message even if they use --jobs or --quiet-build. 2) The user may want to manually replace the symlink with a directory, as noted in the elog message: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=324bf88228b7be64814e99dd96ad73a204a5df63 (In reply to comment #1) > I don't think the message should be triggered very often anyway. Before yesterday, I thought only gnucash and a few others were showing it but, after needing to merge kopete to check it built ok with glib-2.32, some kde/qt packages were installed and, when depcleaned, a lot of them showed this kind of message. > The reasons > that I made it an elog message are: > > 1) The search is time consuming, so the log message is there to notify > people in case they wonder what's consuming the time. By using elog, it > they'll see the message even if they use --jobs or --quiet-build. > The problem of elog is that the message will get recorded in summary.log and, there, it's useless. What is the reason for not showing "einfo" messages with --quiet-build? Also, this message is shown at removal time, not sure if people will wonder on time so much at this stage (removal is usually fast enough) > 2) The user may want to manually replace the symlink with a directory, as > noted in the elog message: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=324bf88228b7be64814e99dd96ad73a204a5df63 I am referring only to the case when symlinks are finally automatically removed by portage, in that case only "The above directory symlink(s) are all safe to remove. Removing them now..." message is shown, no other action is suggested (In reply to comment #2) > The problem of elog is that the message will get recorded in summary.log > and, there, it's useless. It lets the user know why the unmerge consumed extra time. They may be wondering that, and the log will tell them. > What is the reason for not showing "einfo" messages with --quiet-build? This is due to the default PORTAGE_ELOG_CLASSES="log warn error" setting. The einfo messages are not saved by default, because most people don't care about the things like einfo messages generated by epatch. > Also, this message is shown at removal time, > not sure if people will wonder on time so much at this stage (removal is > usually fast enough) It varies. Sometimes it can take a minute or two. (In reply to comment #3) > (In reply to comment #2) > > The problem of elog is that the message will get recorded in summary.log > > and, there, it's useless. > > It lets the user know why the unmerge consumed extra time. They may be > wondering that, and the log will tell them. > But, from my point of view, a user will wonder about consumed extra time while it's consuming time, not after all emerges are run and he/she is reviewing summary.log to complete pending tasks, but that is only my opinion of course :/ > > What is the reason for not showing "einfo" messages with --quiet-build? > > This is due to the default PORTAGE_ELOG_CLASSES="log warn error" setting. > The einfo messages are not saved by default, because most people don't care > about the things like einfo messages generated by epatch. > OK, it's completely reasonable > > Also, this message is shown at removal time, > > not sure if people will wonder on time so much at this stage (removal is > > usually fast enough) > > It varies. Sometimes it can take a minute or two. And what about using a different kind of message, a bit like it's done when some updates are done just after running "emerge --sync" and a message telling updates are running with some ".....", "####"... are shown? The idea would be to do the similar for this and show the message with additive "..." chars while searching is run. This mechanism wouldn't use elog/einfo/ewarn, and could be reused for other similar tasks like collision-protect, protect-owned (In reply to Pacho Ramos from comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > The problem of elog is that the message will get recorded in summary.log > > > and, there, it's useless. > > > > It lets the user know why the unmerge consumed extra time. They may be > > wondering that, and the log will tell them. > > > > But, from my point of view, a user will wonder about consumed extra time > while it's consuming time, not after all emerges are run and he/she is > reviewing summary.log to complete pending tasks, but that is only my opinion > of course :/ This still applies, I keep getting lots of this useless elog messages that need no action from me (but only add noise to the summary.log) with a lot of packages :| You can use the UNINSTALL_IGNORE variable to make it ignore each symlink that you don't care to be notified about (maybe you only have one of them). Note that make.defaults in the base profile already has /var/run and /var/lock in UNINSTALL_IGNORE (they were relatively recently added). Maybe we just need to update the symlink warning message to suggest that you can use UNINSTALL_IGNORE to silence it. Ah, will try it then Per man make.conf UNINSTALL_IGNORE wouldn't work as I expected as it will cause portage to not uninstall that symlinks ever, even if possible:
UNINSTALL_IGNORE = [space delimited list of fnmatch patterns]
This variable prevents uninstallation of files that match specific fnmatch(3) patterns. In order to ignore file collisions with
these files at install time, the same patterns can be added to the COLLISION_IGNORE variable.dence decreases from left to right such
Defaults to "/lib/modules/*".verrides conf, and so forth.
Also, as I have just seen again in summary.log, I would end up needing to add a lot of random symlinks, for example:
LOG: postrm
Directory symlink(s) may need protection:
/opt/Citrix/ICAClient/keystore/cacerts
Searching all installed packages for files installed via above symlink(s)...
The above directory symlink(s) are all safe to remove. Removing them now...
LOG: postrm
Directory symlink(s) may need protection:
/usr/share/doc/HTML/en/konvertible/common
Searching all installed packages for files installed via above symlink(s)...
The above directory symlink(s) are all safe to remove. Removing them now...
LOG: postrm
Directory symlink(s) may need protection:
/usr/share/doc/HTML/en/kioslave/bookmarks/common
/usr/share/doc/HTML/en/kioslave/bzip2/common
/usr/share/doc/HTML/en/kioslave/cgi/common
/usr/share/doc/HTML/en/kioslave/finger/common
/usr/share/doc/HTML/en/kioslave/fish/common
/usr/share/doc/HTML/en/kioslave/floppy/common
/usr/share/doc/HTML/en/kioslave/gzip/common
/usr/share/doc/HTML/en/kioslave/info/common
/usr/share/doc/HTML/en/kioslave/man/common
/usr/share/doc/HTML/en/kioslave/nepomuksearch/common
/usr/share/doc/HTML/en/kioslave/network/common
/usr/share/doc/HTML/en/kioslave/nfs/common
/usr/share/doc/HTML/en/kioslave/sftp/common
/usr/share/doc/HTML/en/kioslave/smb/common
/usr/share/doc/HTML/en/kioslave/tar/common
/usr/share/doc/HTML/en/kioslave/thumbnail/common
/usr/share/doc/HTML/en/kioslave/xz/common
Directory symlink(s) may need protection:
/usr/lib64/python2.7/site-packages/IPython/html/static/mathjax
/usr/lib64/python3.4/site-packages/IPython/html/static/mathjax
And many many more... all of them are in the same case: they are recorded as "elog" messages in summary.log but, once I read them, I don't need to do anything and, then, they are completely useless. This should be simply "einfo" messages, as it's already done by eclasses to announce people that, for example, mime databases are being updated while removing a package
(In reply to Pacho Ramos from comment #8) > Per man make.conf UNINSTALL_IGNORE wouldn't work as I expected as it will > cause portage to not uninstall that symlinks ever, even if possible: > UNINSTALL_IGNORE = [space delimited list of fnmatch patterns] > This variable prevents uninstallation of files that match > specific fnmatch(3) patterns. In order to ignore file collisions with > these files at install time, the same patterns can be added to > the COLLISION_IGNORE variable.dence decreases from left to right such > Defaults to "/lib/modules/*".verrides conf, and so forth. You can always check yourself to see if any of the symlinks you have there can be removed. By listing them in UNINSTALL_IGNORE, you avoid the elog messages, and also the performance hit from having emerge search for owners. > > Also, as I have just seen again in summary.log, I would end up needing to > add a lot of random symlinks, for example: > LOG: postrm > > Directory symlink(s) may need protection: > > /opt/Citrix/ICAClient/keystore/cacerts You'll only see messages like these when you uninstall packages, unless the symlink is removed during an upgrade. Therefore, they shouldn't bother you very often, unless you uninstall lots of packages regularly. > And many many more... all of them are in the same case: they are recorded as > "elog" messages in summary.log but, once I read them, I don't need to do > anything and, then, they are completely useless. This should be simply > "einfo" messages, as it's already done by eclasses to announce people that, > for example, mime databases are being updated while removing a package I think it's better to use elog because there is a performance penalty when searching for owners, and without the elog message it will be less clear to users what has caused the performance penalty. (In reply to Zac Medico from comment #9) > > And many many more... all of them are in the same case: they are recorded as > > "elog" messages in summary.log but, once I read them, I don't need to do > > anything and, then, they are completely useless. This should be simply > > "einfo" messages, as it's already done by eclasses to announce people that, > > for example, mime databases are being updated while removing a package > > I think it's better to use elog because there is a performance penalty when > searching for owners, and without the elog message it will be less clear to > users what has caused the performance penalty. Maybe message could be displayed on terminal, but not stored in /var/log/portage/elog/... ? (In reply to Arfrever Frehtes Taifersar Arahesis from comment #10) > > I think it's better to use elog because there is a performance penalty when > > searching for owners, and without the elog message it will be less clear to > > users what has caused the performance penalty. > > Maybe message could be displayed on terminal, but not stored in > /var/log/portage/elog/... ? What's so bad about having them logged. As explained earlier, you'll only see messages like these when you uninstall packages, unless the symlink is removed during an upgrade. Therefore, they shouldn't bother you very often, unless you uninstall lots of packages regularly. The problem with them being in summary.log is that they are more and more useless lines as, once they are unmerged, the people looking to summary.log doesn't need to take any action and, then, the purpose of logging them AFTER emerge ended is... :/ (In reply to Pacho Ramos from comment #12) > The problem with them being in summary.log is that they are more and more > useless lines as, once they are unmerged, the people looking to summary.log > doesn't need to take any action and, then, the purpose of logging them AFTER > emerge ended is... :/ Since when do log messages necessarily indicate that an action must be taken? The log message serves a couple of goals: 1) Make it obvious what the source of time consumption was. Otherwise, they might not know what consumed the time, and might just assume that "portage wastes time doing unnecessary stuff". 2) Give users an opportunity add the relevant paths to UNINSTALL_IGNORE, if appropriate. As said earlier, I'd like to update the message to mention UNINSTALL_IGNORE. (In reply to Zac Medico from comment #13) > (In reply to Pacho Ramos from comment #12) > > The problem with them being in summary.log is that they are more and more > > useless lines as, once they are unmerged, the people looking to summary.log > > doesn't need to take any action and, then, the purpose of logging them AFTER > > emerge ended is... :/ > > Since when do log messages necessarily indicate that an action must be taken? > > The log message serves a couple of goals: > > 1) Make it obvious what the source of time consumption was. Otherwise, they > might not know what consumed the time, and might just assume that "portage > wastes time doing unnecessary stuff". > The problem is that this doesn't make much sense. Once we review summary.log, all that extra work has already occurred and its likely that admin has even forget about it took longer than normal. On the other hand, this is the kind of message you expect to see WHILE it's running and you wonder about it taking too much time. > 2) Give users an opportunity add the relevant paths to UNINSTALL_IGNORE, if > appropriate. As said earlier, I'd like to update the message to mention > UNINSTALL_IGNORE. I am unsure if this is the desired workaround as probably most people will still want to let portage to its work cleaning the link if neccesary, but they could set this to a lot of random paths leading to probably unwanted results :/ Released in portage-2.2.19 |