Dash Four wrote:
When upgrading from a BDB version to another, you'll need to remove
the BDB environment, which is always incompatible between BDB versions:
'rm -f /var/lib/rpm/__db.*'
That is indeed the case - I figured it out later on. There is a
"posttrans" scriptlet in the .spec file (I use FC), which *should*
take care of this automatically, but doesn't. Why? Because there is a
bug in the libdb-utils package (I used version 5.00).
libdb-utils 5+ *should* obsolete the db4-utils package (as it is a
straight-forward replacement), but doesn't, hence the "postrtrans"
scriptlet, which is dependent on an error message being displayed,
doesn't work and it is why I was getting this error when trying to
upgrade - the "old" db4-utils package is not deleted and because it
shows no error message the __db.00? files are not deleted, so I had to
delete them all manually in the end.
Further to the above, I came across what I think is another bug.
Currently, when I have "%debug_package %{nil}" in my $HOME/.rpmmacros
(or "%define debug_package %{nil}" included in my .spec file directly)
the brp-strip-shared script is NOT included for execution in
"platform.in", therefore shared objects/executables are NOT stripped
(brp-strip is executed, but it excludes shared objects as it executes
"grep -v ' shared object,'").
In other words, what we have is:
platform.in
~~~~~~~~~~~
%__os_install_post \
%{_rpmconfigdir}/brp-compress \
%{_rpmconfigdir}/brp-strip %{__strip} \
%{_rpmconfigdir}/brp-strip-static-archive %{__strip} \
%{_rpmconfigdir}/brp-strip-comment-note %{__strip} %{__objdump} \
%{nil}
That should actually be:
platform.in
~~~~~~~~~~~
%__os_install_post \
%{_rpmconfigdir}/brp-compress \
%{_rpmconfigdir}/brp-strip %{__strip} \
%{_rpmconfigdir}/brp-strip-shared %{__strip} \
%{_rpmconfigdir}/brp-strip-static-archive %{__strip} \
%{_rpmconfigdir}/brp-strip-comment-note %{__strip} %{__objdump} \
%{nil}
since "%{_rpmconfigdir}/brp-strip" contains "grep -v ' shared object,'"
statement which excludes stripping of shared objects, naturally. There
is identical bug in the redhat-rpm-config package, but I already
submitted a report for that (see
https://bugzilla.redhat.com/show_bug.cgi?id=988812).
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
