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