On Oct 27, 2006, at 9:36 PM, Bob Proulx wrote:
Fulko.Hew@xxxxxxxxx wrote:
I would, but the std tarballs such as (in the case of bash), from
FSF.org don't come with spec files. Do you suggest that I hunt
down Redhat's version of a source?
Not necessarily Red Hat. There are many distros that use rpm. And
there are many legacy Unix systems that local admins are using rpm as
an add-on to manage packages. I would be happy to share with you my
own very generic spec file that I use on legacy Unix systems but it is
too big to post to the mailing list.
I think needing to do that is incorrect. I would fix it so that
they
will not be needing to erase bash "for other technical reasons". It
will be a source of problems.
Perhaps, but the person who built our package manager manager
chose to rpm -e followed by rpm -i, whenever a package is upgraded.
Ugly.
Ugly, but workable. The ugliness is the window within which, say,
libraries are unavailable in an erase-before-install scenario.
You will probably have to script all your upgrades to do -e/-i within
a loop.
(aside) There's worse than -e/-i for installs (in increasing order of
insanity):
a) rpm2cpio (i.e. using *.rpm purely as a rich archival format)
b) alien (convert *.rpm to *.deb, then install/erase. LSB is kinda
fond of alien)
c) IBM WebSphere (they are doing some astonishing things to/with rpm)
This is probably due to the reason that during the install process
(because its actually install and not upgrade), we have to be able
to 'install' older versions of an RPM incase the 'new' rpm failed
because and embedded application failed within the new rpm,
or because the customer decided that they wanted to fall-back
to an older version of the same rpm
If you have a definite "Go forward successfully or go back to
original successfully."
constraint, then you should look carefully at using --repackage/--
rollback with rpm.
The entire process is automated in rpm-4.4.5 and later. Note also
that reliable automagic
rollbacks requires reliable packaging, i.e. no vendor is testing
their packaging with
rollbacks, and so there can be reliability problems. All I'm saying
is test before
you promise some customer something you cannot deliver.
I expected you to say because of the ordering of script execution in
the %post and other scripts. If the %post is broken then that is the
only method of dealing with the problem from a user perspective.
(Let's not talk about triggers because that would be a developer
perspective not a user perspective.)
Scriptlet failures are rather easy to detect if/when using --root to
install into
a chroot. OTOH, working around broken scriptlets on end-user machines
is trickier.
I would still go with the --upgrade and the --oldpackage options.
Otherwise nothing will ever be able to depend upon bash.
Yep.
See above... I think rpm -e is my only approach. Correct me if
I'm wrong.
If the -e were accompanied by --nodeps then the erase would proceed
even if things depended upon bash. But if bash provides /bin/sh then
rpm install itself will probably be broken. Because you have not run
into this I infer that you are running on a legacy Unix system where
bash is simply an addition shell.
There's also rpm -e --justdb --nodeps which removes the database
entry and does
nothing else.
Get rid of the header in the database, then do with the package contents
whatever is necessary.
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
