On Thursday 18 November 2010, Kevin Kofler wrote:
Does this even need %pretrans at all? Rex Dieter used this in
kde-settings-
kdm:
%pre kdm
## KDM fixup(s)
# [snip similar hack for a moved/symlinked %config file]
# handle %%_datadir/config/kdm -> /etc/kde/kdm
[ -d %{_datadir}/config/kdm -a ! -L %{_datadir}/config/kdm ] && \
%{__mv} -v %{_datadir}/config/kdm %{_datadir}/config/kdm.rpmorig ||:
AFAIK, this worked while it was relevant.
It probably did, and because the above is related to config files, leaving
behind *.rpmorig is quite appropriate IMO. But leaving such cruft behind is
not that fine for non-config files.
This may be old news to some, but before running some tests (and posting my
previous mail in this thread), I thought/remembered that it would be possible
to solve this problem with a %pre script like:
%pre javadoc
[ $1 -gt 1 ] && [ -L %{_javadocdir}/%{name} ] && \
rm -f %{_javadocdir}/%{name} || :
However, while this does work in the sense that it will allow the upgrade to
happen and the %{_javadocdir}/%{name} symlink turns to a dir and has the
correct contents, for some reason rpm leaves the
%{_javadocdir}/%{name}-%{version} dir and its contents which were there in the
previous version of the package but are no longer in the new one behind,
unowned. This happens no matter whether the %{_javadocdir}/%{name} symlink
was owned by the previous package (a couple of specfiles that demonstrate this
are attached), created by it in %post without owning it, or even manually
created completely outside of rpm. This is with rpm-4.8.1-2.fc13.x86_64 on
F-13.
In my opinion this sounds like a bug in rpm, and somewhat a different one
compared to the usual problem of trying to overwrite a dir with a symlink
(which fails with a cpio error message) or install a dir with some contents in
place of a symlink to a dir (which ends up installing the contents into the
old symlink's target dir and doesn't turn the original symlink into a dir).
Not sure if I should file a bug about this or if it's already covered by the
existing dir<->symlink related open issues. Panu?
The %pretrans approach I posted does not have this problem. Even given the
inherent problems mentioned with %pretrans, I don't know of a better way to
solve this, and I personally find it quite acceptable. Getting rid of the
unversioned symlinks gradually during a few releases (e.g. drop it in F-N,
reintroduce as dir in F-N+X) would work as well, but that would leave releases
F-N..F-N+X-1 without anything unversioned in place which is bad, in my opinion
clearly worse than the %pretrans approach.