Bug 428098 - sys-apps/portage-2.1.11.9: elog is used for useless "Directory symlink(s) may need protection" messages
sys-apps/portage-2.1.11.9: elog is used for useless "Directory symlink(s) may...
 Status: RESOLVED FIXED None Portage Development Unclassified Core - Interface (emerge) (show other bugs) All Linux Normal enhancement (vote) Portage team 484436 Show dependency tree

 Reported: 2012-07-25 20:36 UTC by Pacho Ramos 2015-05-19 19:46 UTC (History) 0 users ---

Attachments

 Note You need to log in before you can comment on or make changes to this bug.
 Pacho Ramos 2012-07-25 20:36:26 UTC I see some packages logging messages about: LOG: postrm Directory symlink(s) may need protection: [...] But, in all cases, "The above directory symlink(s) are all safe to remove. Removing them now..." I think that this kind of message should only use "elog" when that symlinks are not safe to remove, if they are safe to remove, I think that "einfo" should be enough. Thanks a lot Reproducible: Always Zac Medico 2012-07-25 22:17:34 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 Pacho Ramos 2012-07-26 06:30:43 UTC (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 Zac Medico 2012-07-26 08:30:58 UTC (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. Pacho Ramos 2012-07-26 18:05:32 UTC (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 Pacho Ramos 2015-04-20 08:59:21 UTC (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 :| Zac Medico 2015-04-20 17:43:59 UTC 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. Pacho Ramos 2015-04-20 20:15:11 UTC Ah, will try it then Pacho Ramos 2015-04-26 07:39:59 UTC 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 Zac Medico 2015-04-26 21:35:01 UTC (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. Arfrever Frehtes Taifersar Arahesis 2015-04-26 21:53:41 UTC (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/... ? Zac Medico 2015-04-26 22:09:20 UTC (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. Pacho Ramos 2015-04-27 20:48:56 UTC 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... :/ Zac Medico 2015-04-27 20:58:28 UTC (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. Pacho Ramos 2015-04-28 21:07:49 UTC (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 :/ Brian Dolbec 2015-05-19 19:46:35 UTC Released in portage-2.2.19