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

Re: question re: best practices,



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.

We store the spec files with the version number.  However, we
dynamically generate the release number, which is a date_time stamp.
This ensures each build is unique and increasing number.

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...)

We also check in the sources for all our builds into CVS, and the
specs pull them out.  We've built a layer on top of "rpm/cvs" which
does this for us.  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. :-)

Rob






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