Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 428098 - sys-apps/portage-2.1.11.9: elog is used for useless "Directory symlink(s) may need protection" messages
Summary: sys-apps/portage-2.1.11.9: elog is used for useless "Directory symlink(s) may...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 484436
  Show dependency tree
 
Reported: 2012-07-25 20:36 UTC by Pacho Ramos
Modified: 2015-05-19 19:46 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 Pacho Ramos gentoo-dev 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
Comment 1 Zac Medico gentoo-dev 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
Comment 2 Pacho Ramos gentoo-dev 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
Comment 3 Zac Medico gentoo-dev 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.
Comment 4 Pacho Ramos gentoo-dev 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
Comment 5 Pacho Ramos gentoo-dev 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 :|
Comment 6 Zac Medico gentoo-dev 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.
Comment 7 Pacho Ramos gentoo-dev 2015-04-20 20:15:11 UTC
Ah, will try it then
Comment 8 Pacho Ramos gentoo-dev 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
Comment 9 Zac Medico gentoo-dev 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.
Comment 10 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/... ?
Comment 11 Zac Medico gentoo-dev 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.
Comment 12 Pacho Ramos gentoo-dev 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... :/
Comment 13 Zac Medico gentoo-dev 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.
Comment 14 Pacho Ramos gentoo-dev 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 :/
Comment 15 Brian Dolbec gentoo-dev 2015-05-19 19:46:35 UTC
Released in portage-2.2.19