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: