Bug 741145 - Mock RPM update not silent
Summary: Mock RPM update not silent
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 16
Hardware: All
OS: All
low
low
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-26 01:06 UTC by David Kovalsky
Modified: 2014-03-31 23:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-21 17:26:50 UTC


Attachments (Terms of Use)

Description David Kovalsky 2011-09-26 01:06:18 UTC
When running an update from updates-testing this evening I've noticed this:

...
Updating       :mock- 1.1.15-1.fc14.noarch
ln: creating symbolic link `/etc/mock/default.cfg': File exists
Updating       : tzdata-java-2011k-0.1.20110921.fc14.noarch
...


There's no reason for such a message to be printed during an update. It's not fatal so I suggest it goes to /dev/null.

Comment 1 Clark Williams 2011-11-11 22:01:24 UTC
That's a yum message, not a mock message. It's because that file is marked as noreplace,missingok. 

Not a bug.

Comment 2 David Kovalsky 2011-11-14 14:22:52 UTC
Hey Clark, 

the message reads like from ln when a file exists, not yum.

I believe it's line 84 in the specfile (%post):
 84         if [ -e %{_sysconfdir}/%{name}/$cfg ] ; then                                         
 85             ln -s $cfg %{_sysconfdir}/%{name}/default.cfg                                    
 86             exit 0                                                                           
 87         fi   


Where if there's an existing default.cfg, ln will complain. I still believe it should either be forced (-f) or sent to /dev/null.


Not much relevant for F14, but still should be fixed for future releases.

Comment 3 Clark Williams 2011-11-25 15:30:01 UTC
Hmmm. I was confused as to why you were getting that message, since the full block of code looks like this:

if [ ! -e %{_sysconfdir}/%{name}/default.cfg ] ; then
    arch=$(uname -i)
    for ver in %{?fedora}%{?rhel} rawhide ; do
        cfg=%{?fedora:fedora}%{?rhel:epel}-$ver-$arch.cfg
        if [ -e %{_sysconfdir}/%{name}/$cfg ] ; then
            ln -s $cfg %{_sysconfdir}/%{name}/default.cfg
            exit 0
        fi
    done
fi


Now I'm wondering if when this happens default.cfg is a dead symlink, so -e fails but the ln -s fails because the symlink exists. I may need to change this block to check for a broken symlink.

Comment 4 David Kovalsky 2011-11-25 16:09:04 UTC
Clark, you nailed it. In my case it's a dead symlink. 

I quickly ran through `man test' and I haven't found a test for a dead symlink. I believe though that you just skip that part if the symlink exists. If someone created the symlink, they probably knew what they were doing (perhaps no an unmounted filesystem? or in my case, to a file which has been removed in one of the updates). 

Best I could figure out is adding a check if it's a symlink (-l or -H):

 * exists -> don't touch

 * not exists + is a symlink -> dead symlink, don't touch
 * not exists + not a symlink -> create the symlink

Hope this helps.

Comment 5 Clark Williams 2011-11-25 16:16:15 UTC
Ah but what if the symlink exists but doesn't point to an existing file (which is what I think is going on here)? In that case I think we should delete the dead symlink and recreate it with it pointing to a valid file.

Comment 6 David Kovalsky 2011-11-25 19:07:56 UTC
That could be one of the solutions. 

Alternative side of things is that the symlink is actually user preference, so if the user picks for the symlink to point "nowhere" (like for example to a tree that's not mounted during updates, like /home or USB drive), overwriting it with every update might not be a good idea. 


I would personally prefer not to touch it if it exists, wherever it points. 


But I bet you know your user preferences way better then I do :) I trust you'll pick the best solution, not only for me.

Comment 7 Clark Williams 2012-01-02 16:49:12 UTC
I think the best thing to do here is probably the most obvious. We should just force the symlink if the -e test fails (meaning the destination of the symlink doesn't exist). 

We could check that it's a symlink (test -L) and check to see if it's pointing to something with the readlink program but that's probably overkill. 

I'll add that do my working branch and push it out in the next release.


Note You need to log in before you can comment on or make changes to this bug.