Re: RFC: Central version control for Debian
On Mon, Jan 29, 2001 at 10:59:14PM +0000, Thom May wrote:
> The BSDs use CVS for their core system. Ie kernel, basic system requirements,
> that sort of thing. you'll see the package tree is (a) fairly separate (b)
> not full of packages anyway, just Makefiles and patches.
The base system is where the auditing is concentrated, and for good reason. I
am just suggesting ways in which Debian could benefit from similar tools and
> > Eventually, it would be nice to allow maintainers to commit changes to the
> > repository. Things get much more complicated here. Debian has a lot more
> > developers than OpenBSD, and we seem to make changes much more frequently.
> > Developers could easily step on one another's toes. Package maintainers
> > need to be able to ensure that they don't miss ANY changes that are made to
> > their packages, lest unexpected bugs arise (or worse, malicious ones).
> I think there would be too many problems with this idea. 1) who decides when
> to create branches, roll releases, etc? the maintainer? the cvs admin? the
> release manager? some random maintainer who wants a new ver of package foo
> because their package has just been upgraded and it depends on a new version
> of foo? 2) It's too easy to miss such a change. If you go on holiday for a
> couple of days and someone checks in a security fix, and you don't realise,
> that's going to be a fairly awkard situation for all concerned. It's equally
> do-able with packages, I agree, but cvs is a lot more immediate.
I imagine that each area of the tree would be subject to its own access control
policy. Notification of changes is easy, as I noted later, as it can be
automated. A lot of coordination would be necessary to avoid conflicting
changes and other such messes, though. The scalable solution would be for each
maintainer to determine the access control policy for his/her packages.
> > - Maintainers adopting orphaned packages would have access to the complete
> > history of the package, to help avoid repeating old mistakes, and to help
> > understand why changes were made.
> That's what the changelog is for.
The changelog is too granular, and has no mapping to actual changes in the
source code. CVS supplies that mapping with log messages and diffs for each
> > - A hypothetical security auditing team could easily and methodically audit
> > the entire source tree.
> *falls off his chair* Debian has ~600 developers. if each of them only
> maintains 4 packages, each of around a megabyte of source code ( a gross
> simplification, and doesn't take into account things like X, emacs, gnome,
> kde etc). This is 2.4 gig of source code. Not to mention documentation.
I didn't claim that it would be quick or easy. Such a project (as has already
been suggested here) would probably start with the (relatively manageable) base
> > - Peer review could increase, as well as additional sharing and
> > collaboration between maintainers.
> potentially. but everyone has access to the sources - if they want them,
> 'apt-get source blah' is no harder or less useable than 'cvs -z3 co blah' and
> you still have to send email/patches (assuming politness and not just
> randomly applying fixes to cvs) to the maintainer either way.
True, but what is the analogue to cvs diff -rrev1 -rrev2? cvs log <file>?
These are powerful tools for keeping aware of what is going on with a source
I subscribe to debian-bugs-dist, and sometimes to try to help investigate a
bug, I'll download and extract the source package and poke around. But if
something broke between the previous revision and this one, I have to guess
(based on the package changelog and my knowledge of the software) where to look
for the problem. Even knowing exactly which files changed between two
revisions would be a huge help. Members of the QA team would likely agree.
> > etc., etc. The biggest barrier to making this work seems to be deciding
> > who should be able to commit changes where. CVS may not currently be
> > flexible enough for our needs; it would be nice, for example, if certain
> > users (the security team) were able to create a branch for a package, but
> > not trample over the maintainer's current stuff.
> Tricky with CVS, i think.
Impossible in the current implementation. One needs write access to the
_directories_ in the repository in order to make any changes at all.
> >Tracking is relatively easy; the official maintainer address could be sent
> >mail whenever a change was committed to one of their files.
> Infrastructurally it'll be fairly intensive I guess - it's machine intensive
> because all commits have to be done to the same source, so you can't
> distribute queues, you wind up with two sets of source code for each package
> - one in cvs, one on debian package mirrors - will you need anonymous access?
> if so, will you want a network of anonymous mirrors, in which case, you have
> yet more rsync traffic, etc...
The answer may be that Debian is simply too big to be manageable using such a
system. One could also argue that Debian is simply too large and complex to be
secure. In that case, we should focus on doing what we can for a subset of
> > Comments?
> See above. I think it's a good idea for the core of debian - base system,
> installers, docs etc (all the stuff already in cvs ;) ) but for the packages
> it's a massive commitment, and I can't see how you'd gain that much.
The Debian-specific parts are easy, and wouldn't add much value. Debian's
strength is in forming a coherent, consistent whole out of many, many
dissimilar parts from different sources.
I have a 9gb disk looking for a use; I may just extract a useable subset of
Debian into a CVS tree there and see what happens. The components for
importing new versions should be relatively simple.