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.
That's a yum message, not a mock message. It's because that file is marked as noreplace,missingok. Not a bug.
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.
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.
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.
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.
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.
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.