Changes in Java packaging guidelines - RFC

Ville Skyttä ville.skytta at iki.fi
Fri Nov 19 16:08:23 UTC 2010


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo-2.spec
Type: text/x-rpm-spec
Size: 666 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101119/ad9d0765/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo-1.spec
Type: text/x-rpm-spec
Size: 659 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101119/ad9d0765/attachment-0001.bin 


More information about the devel mailing list