Re: question re: best practices,

[Tim Mooney <mooney dogbert cc ndsu NoDak edu>]

In regard to: Re: question re: best practices, , Rob Nagler said (at 4:04pm...:

>Thomas Vander Stichele writes:
>> Does it make sense to use the versions in the filename to be able to keep
>> track of older packages as well ? What do other packagers do ?
>
>I think it makes sense to store the spec files with the version
>number.  We're currently upgrading from 6.2 to 7.2.  We will need both
>versions of our custom rpms around for quite some time.

What's the advantage to storing the spec with the version, rather than
using tagging or just using cvs' `diff' capability to diff two previous
revisions?

We store all our custom specs in a single CVS repository (too), but that's
kind of counter to the way CVS was meant to be used.  A CVS repository is
generally some kind of group of files that relate to each other, that
together make up a coherent whole.  A group of (essentially unrelated)
specs in a single repository isn't the "CVS way".

What my site probably should have done, if we had been more familiar with
CVS when we set all this up years ago, is set up a hierarchy of our local
stuff, such as

	local/rpm/rpm.spec
	local/rpm/some-local-patch-for-rpm
	local/sendmail/sendmail.spec
	local/sendmail/some-local-patch-for-sendmail
	etc.

Then it would be more logical to use branching and tagging to track the
specs (and any local patches or additional files) that go with the build
procedure for a particular package.  One could *also* use `cvs import' to
include the source distribution in the CVS tree too, though that can get
to be a big use of storage.

>The big problem to me is the Red Hat Network.  If it updates, say,
>apache-1.3.22 to 1.3.26, and we have built apache-1.3.24, it will
>automatically upgraded and blow away our custom build.  I was thinking
>about renaming the spec files, e.g. bivio-apache-1.3.24.  However, it
>needs to provide "apache" for other packages which require it.  How
>would this interact with up2date/rpm -U?  (OK, I'll try it, but more
>pressing problems right now...)

Have you considered instead using something like `autorpm', and a bit of
scripting?  You're using your own "Vendor:" tag in all RPMs you build,
right?  You could query the RPM database, find all RPMs that have your
vendor tag, and then skip them when using autorpm to update your other
software.

>The big problem to me with maintaining all these
>different specs is that there is so much duplication and maintenance
>problems.  We ended up adding a "include" feature just recently so
>that we could share more between specs.  Now our internal perl package
>specs contain only two lines.  For those curious, you can see/use the
>code at: http://petshop.bivio.biz/src?s=Bivio::Util::Release
>(Yes, this is a "make make" for rpm specs. :-)

A student I worked with years ago abstracted all this into a set of `m4'
macros and actually generated complete spec files as a target by building
them from a `package.spec.m4' file and the relevant m4 files that package
relied upon.  This is very similar to how modern sendmail.cf is built from
a library of small m4 files.  The nice part about the system is that if
you fix a bug in one of your m4 files, you just rebuild all your spec
targets from the m4 sources, and they all have the updated fix right away.

I kind of wish we had adopted his system, though at the time none of the
rest of us that were building RPMs were very comfortable with m4.  We
too toil under the weight of managing hundreds of spec files.  I had a
minor bug in the %clean section of one of the spec files that I used
as a template for many later projects, and I'm still finding spec files
that have that old bug...

Tim
-- 
Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164