Re: Debian violates GPL?
John Goerzen <jgoerzen@complete.org> writes:
> 1) Pristine tar.gz files cannot be generated
Depends on what you mean by pristine. The files inside the
.orig.tar.gz that gets regenerated from CVS wil be byte for byte
identical to the ones in the upstream tarfile, and the directory names
will be the same. The only differences should be those caused by
version differences in tar/gzip. And this should only be used in rare
curcumstances anyway, so as long as the contents are identical, who
cares about the binary diff of the tar files?
> 2) Some tar.gz files contain binaries themselves
CVS, as long as you tell it which files are binary, has no problems
with this.
> 3) Takes a lot more space in most cases
Maybe as compared to storing a single .tgz file, but not after you've
got 10 upstream releases in there (which CVS stores as diffs). Also
hard drives are cheap -- it's not like we're going to mirror this
everywhere. This would be primarily for archival purposes.
> 4) Owner/permissions can be lost (permissions can be an issue)
If this turns out to be a big deal, then we can just add a wrapper
level that keeps this information as a separate branch and our
"checkout" script uses it to reconstruct the proper tarfile (a la
fakeroot) or tree, but I'm having a hard time imagining many cases
where this would be a big issue that we couldn't farily easily work
around.
> 5) How can you refer to a CVS directory full of ,v files
> that can change with a md5sum in changes or dsc or whatever files?
You don't. You always export a tree before doing something like
that. An export (as opposed to a checkout) has none of the ./CVS
administrative files in the tree.
I'm not saying we absolutely use CVS as our historical archive (which
may be useful for purposes other than satisfying the GPL), but I do
think it's worth considering.
I, for one, think it would be quite cool to be able to say something
like:
cvs checkout -r release_hamm -d rxvt package/rxvt
cvs checkout -r release_bo -d rxvt package/rxvt
when I want a particular version.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: