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

Re: PDR -- Package development repostory to replace SRPM's?



Ralf S. Engelschall wrote:
Many thanks for establishing such a service.

Jeff, I agree. This will be very useful!


But I strongly recommend you to leave out vendor tarballs and other
downloadable files from CVS. CVS handles those binary files very bad
and they really bloat up the CVS tree (as you already recognized ;-).
Especially, on package upgrades they all are moved into the CVS Attic/
subdirs and get replaced with new files (because of versioned filenames)
and this way the CVS bloats up even more dramatically. And keep in mind
that not just the CVS checkouts require backbone bandwidth and large
disk spaces. It is also impossible to reasonable work with the stuff
(try a single recursive grep(1) for something and you'll see ;-)

I have been doing CVS repositories of RPMS since approx 1996. My layout was slightly different then this new repository, you can see it at http://gate.crashing.org/cgi-bin/cvsweb.cgi/


(While completely out of date.. it's still possible to see what we did way back then.. FYi that repo isn't from '96.. but you get the idea.)

We always checked in our tar balls, and other upstream sources. It was the only way to ensure that we could properly reproduce an package. cvs admin -kb is the right way to do it. (We had a way to automatically do that on checkin of new items.)

I view this less of a "source code repository", and more of a "file system with revision control".

(FYI I know of many other folks both commerical and open source that use the exact same repository layout as listed at the above URL.) The additional advantage of a system like this is it allows you to create an automated build system. Feed is a branch, tag, etc it suddenly has everything. Iterate through the items (in build dep order), and bingo you have a product.

CVS is cool because lots of people are already used to it and there
are nice addons available. But if you want to use CVS for RPM source
packages, I recommend to look at the OpenPKG setup: we have for each of
of our 600 packages made a split into original files (.spec, .patch,
etc -- all we provide) and third-party files (.tar.gz, etc -- all which
can be downloaded). The first stuff we keep version controlled in a
central CVS repository (http://cvs.openpkg.org/). The second stuff we
just keep on our FTP server (ftp://ftp.openpkg.org/sources/DST/) as
a last copy (for safety in case it is no longer downloadable). This
separation balances the data best IMHO: we have a reasonable small CVS
which everyone can easily checkout or browse and work with.

While this works, it massively complicates the build process. It can also complicate the user/developer from getting the correctly associated items. With an all-in one CVS, yes the main CVS repository is large... but no larger then just keeping around all of the source versions. Diffs are a non-issue w/ '-kb'. And when a user checks out a chunk of the repository (a directory/module) they get everything they need to produce a single rpm.


While I would have separated the sources from the specs (similar to how a SRPM installs), a fully populated repository, IMHO, is the only way to go for long term maintenance purposes.

--Mark




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