[lug] rpm build question

[rm at fabula.de]

On Wed, Dec 11, 2002 at 03:36:48PM -0600, Michael J. Hammel wrote:
> On Wed, 2002-12-11 at 09:30, Harris, James wrote:
> >I have a sort of "best practice" type question for building an RPM.  Very
> > simply, I've created an SRPM that will install an app, along with its
> > appropriate man pages (dur).  However, on RH 7.3 and 8.0, one of those man
> > pages is now included in the standard man-pages rpm so it causes a conflict.
> > On 7.2 and below it is not and I want to include it in the installation.
> 
> > Is there logic that I can put into the .spec file that can identify the
> > rh-release and then only include the man page when it is needed, or should I
> > create two SRPMs, one with the file and one w/o?
> 
> I haven't built any RPMs myself though I've looked at the documentation
> on how to do so.  Most packaging systems (RPM included) have pre- and
> post-install steps that allow you to script what should be done.  You
> should look for these pre- and post-install steps for RPM to do what
> you're trying here.  

I've not the deepest understanding of RPMs either (usually use APT/dpkg)
but ...

> There are a number of ways to handle this situation.  For a man page one
> of the simplest would be to check for the existance of the man page in
> the pre-install and, if it exists, move it out of the way.  After you
> package is installed, you can check for the old version and, if it's
> there, move your version to a saved location and the move the old one
> back.  That way other packages won't break.  Your package's removal
> script can then check for you version of the man page as (for example)
> manpage.mypackage and, if it exists, remove that instead of the real man
> page (possibly by using the temporary move trick you used during
> installtion - but in reverse).

... this is a rather dangerous approach: suppose you do this and replace
foo.man from package blah with your version. Now iof the user chooses to
deinstall package blah the manpage (your version!) will be removed -
suboptimal. Pre/post-install scripts should not modifiy the set of installed
files (or the package manager will be confused about the ownership of a file).

Ralf Mattes


... who doesn't have a convioncing solution either ...