On Wed, Jun 02, 2004 at 09:20:43PM +0200, Thiemo Seufer wrote: > > The idea is have to have a debian/patches/ dir that contains all > > patches, similar to how many of the lots of little patches systems > > work these days (CDBS? or the .dpatch stuff in the glibc packaging), > > and the .diff.gz doesn't touch anything outside debian/. Build > > preparation applies these patches, as many as possible for all > > architectures, and if needed conditionally. > > Then we have some debian-specific kernel tarball and a bunch of assorted > patches, not an (as far as possible) unified source tree.
We have a pristine (well minus the parts considered non-free) + debian build infrastructure + patchkit whereas the latter two are in the .diff.gz. > If that's the > preferred form, then why do we need a version control system for it? Because we a) want to allow multiple people to colaborate on it b) document past versions and changes aka the usual reasons for a SCM. > Furthermore, this scheme doesn't allow arch-specific kernel packages > without duplicating the debian/patches/ dir. Well, I was always arguing against the debian-specific kernel packages. We can of course find a way to share the the patches via a kernel-patch package required by all images, but this starts to get as messy as the current situation real soon.
