Re: How to handle erasing an RPM that contains a mandatory file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




rpm-list-bounces@xxxxxxxxxx wrote on 10/27/2006 12:55:14 PM:

> Fulko.Hew@xxxxxxxxx wrote:
> > I've build an RPM for 'my' version of 'bash'.
>
> I recommend starting from a known good packaging of bash and then
> simply making your modifications to it.  Then you won't have to be
> doing these types of hacks that you are now trying to do.

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?

> > But (for other technical reasons) someone in the future will
> > eventually issue an 'rpm -e bash' during our upgrade procedure,
>
> 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.
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

I don't think that rpm allows you to upgrade to an older version.

> > What is the recommended technique to:
> >
> > a) allow 'rpm -e bash' and avoid the dependency complaint/failure?
>
> Don't do it.

See above... I think rpm -e is my only approach.  Correct me if I'm wrong.

>
> > b) prevent the binary from being removed during package removal?
> >    or how can you maintain a copy of the binary across package removal.
>
> Don't do it.  Simple is better than complicated schemes to work around
> problems caused by doing bad things.
>
> Why do you want to erase bash but leave it on the system?

See above.  Its a side effect of a system requirement.




This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux