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

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

On Wed, Oct 01, 2003, Jeff Johnson wrote:

> [...]
> In the interest of looking seriously at build dependency
> loops involved in bootsrapping a distro, I've set up a
> publci CVS repository for exploded severn2 *.src.rpm's at
> [...]
> Note: The cvs.colug.net repository is ~2GB in size.
> [...]
> Another reason for exploding *.src.rpm's into a repository
> is that I believe that src.rpm's are not the most effective
> means for distributing software.
> Don't misunderstand me, src.rpm's make very good bricks, and src.rpm
> bricks usually come with the implicit rpm guarantee that the src.rpm
> was produced by taking virgin sources, applying patches, and running
> a spec file through rpmbuild from soup to nuts. That is a very sensible
> guarantee for a brick.
> However, src.rpm bricks, just like *.tar.gz, hide the internals. Say
> a package has been rebuilt, and the Release: tag has been incremented
> to reflect the change.  There is no way to discover that nothing else
> of interest has changed in the src.rpm without downloading the entire
> brick. Brick's are bandwidth heavy.
> [...]

Many thanks for establishing such a service.

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

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.

                                       Ralf S. Engelschall

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