[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
statistics:

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
exist:

- 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: