Re: RFC: Central version control for Debian
On Tue, Jan 30, 2001 at 03:33:52PM -0800, Joey Hess wrote:
> At the past two Atlanta Linux Showcases, there have been two main
> themes of discussion. One is autobuilding all of Debian (and
> build-dependancies are making that more and more possible, though there
> are still hurdles). The other is checking it into cvs.
>
> The idea we eventually decided would be a good one is to set up a system
> and import all of the sources in debian into it. After that, the system
> sits there and tracks packages as they are installed into the archive each
> day, and grabs the new version, checking it into cvs.
>
> The resulting cvs archive would be generally read-only, at least in the
> beginning. Some developers may eventually opt to use it as the canoical
> archive for their package (typcially people who have been maintaining
> their own cvs repositories, and groups like the boot-floppies, I guess --
> no need for two cvs repositiories in these cases).
This is precisely what I'm proposing, though with a subset of all packages. As
many people have been quick to point out, a CVS tree holding all of the sources
for Debian would be a formidable beast to host and maintain.
In these discussions, did anyone discuss what to do about source packages which
use DBS and similar arrangements? I skipped such packages in my CVS trial run
(7 out of 73 required/important packages), as they would take up an enormous
amount of space as new versions were imported, and the result is not useful
enough to justify the space required.
I will admit that I don't like repackaged upstream source very much. I
understand the problems it is meant to solve, and it solves them to some
extent, but at too high a cost. Is there any effort to improve our source
package format to make this unnecessary?
> But the good thing about doing it this way is it doesn't really change
> how things are done now. Developers can opt to not use cvs if they
> don't want to, and their uploads will still be automatically checked in.
>
> There are some hurdles though:
>
> - system size
>
> About 2 x the total unpacked source size of unstable, or 25 gb. Call
> it 30 gb to be safe, and this will need to be upgraded from time to
> time just as does the debian archive.
As a trial, I will be maintaining an archive of required, important and
standard packages on my local system, where I have 9 gigs to devote to this
project. This should give us some real-world numbers for how much space will
be required over time. Should we decide to deploy this on a grand scale, it's
just a matter of scaling up disk and CPU usage.
> - checking everything into cvs
>
> This is a bit of a bear. Upstream tarballs that have CVS directories
> or symlinks in them are the main problems. Other problems include
> figuring out which files are binary and checking them in with -kb.
> These problems are all surmountable though.
To start, I will be importing everything with -kb. The right thing to do is
probably to turn on keyword substitution ONLY for debian-only files. The
optimal setup would be to enable keyword substitution only for certain
revisions; then modified upstream files would get new keywords. I don't think
that CVS supports this.
I see that cvs-inject will prompt and remove symlinks; this is OK for, e.g.
packages that use autoconf, libtool and friends, which can be instructed to
restore symlinks that they use, but in other cases it might be better to
flatten links to files. Symlinks to directories just lose. cvs-inject could
be modified to create a small script to restore the symlinks, which could be
called as part of the build process.
--
- mdz
Reply to: