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.
Name: foo
Version: 2
Release: 1%{?dist}
Summary: Dummy test package
Group: Development/Debug
License: Public Domain
URL: http://fedoraproject.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%description
%prep
%build
%install
rm -rf $RPM_BUILD_ROOT
install -dm 755 $RPM_BUILD_ROOT%{_javadocdir}/%{name}
echo "Hello from %{name}-%{version}" > \
$RPM_BUILD_ROOT%{_javadocdir}/%{name}/bar
%clean
rm -rf $RPM_BUILD_ROOT
%pre
[ $1 -gt 1 ] && [ -L %{_javadocdir}/%{name} ] && \
rm -f %{_javadocdir}/%{name} || :
%files
%defattr(-,root,root,-)
%{_javadocdir}/*
Name: foo
Version: 1
Release: 1%{?dist}
Summary: Dummy test package
Group: Development/Debug
License: Public Domain
URL: http://fedoraproject.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%description
%prep
%build
%install
rm -rf $RPM_BUILD_ROOT
install -dm 755 $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version}
echo "Hello from %{name}-%{version}" > \
$RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version}/bar
ln -s %{name}-%{version} $RPM_BUILD_ROOT%{_javadocdir}/%{name}
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%{_javadocdir}/*
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
