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

Re: RFC: Central version control for Debian

On Tue, Jan 30, 2001 at 05:07:41PM -0500, Matt Zimmerman wrote:

> Last night, I downloaded source for all required and important packages, and
> fed them into CVS with cvs-inject.  The compressed sources (tar.gz, diff.gz,
> dsc) were 70M.  These packages used DBS or a similar setup, with repacked
> upstream sources in the tar.gz, so CVS is next to useless for them:

Today, I imported the rest of standard into my CVS repository.  Here are some

142 source packages 			173Mb
121 source packages made it into CVS	138Mb
Repository size				598Mb
Average source package size		  0.82Mb
Average repository size per package	  4.94Mb
Checked-out CVS tree			593Mb

Importing all 138 packages (including verifying the .dsc signatures) on my
350MHz PII took:

real    68m37.044s
user    13m20.870s
sys     5m53.530s

...on one of the slowest SCSI disks in my system (at 10Mbits/sec).  The only
problem packages are:

- Unextractable source packages (ae).  This should be fixed shortly.

- Non-native packages with no diff.gz (this confuses cvs-inject):

doc-linux       fdflush         mime-support    perl-base
dpkg-scriptlib  mig             nfs-utils       sysvinit

  I think that cvs-inject can be fixed to allow these packages to work.

- Repackaged upstream source (DBS and similar).  Unfortunately, this includes
  several important packages, especially in the context of a security audit:

gcc-2.95        libnss-db       pam             silo
glibc           openldap2       ppp             yaboot
gpm             openldap        shadow          zlib

I don't know what to do about this last set of packages.  Perhaps maintainers
of these and similar packages would like to speak up about what they gain from
using such a format, and how we can come up with a solution that meets their
goals without compromising a CVS effort.  As far as I know, these benefits

- The ability to separate out Debian changes to upstream source from the
  packaging infrastructure (debian/).  This has many advantages, especially
  when coordinating merging of patches upstream.  Patches can be separated into
  individual files, and applied in a defined order.

- The ability to combine multiple upstream tarballs

Both of these could be addressed with a new source package format pretty
easily.  Unfortunately, I don't think this can be done without breaking
backward compatibility, but this is a necessary evil.

 - mdz

Reply to: