Hi folks After some time I thought about this again and started an implementation. The preview repo for linux-2.6[1] exists but is not yet usable. I updated my original proposal with the comments I got on the topic. Bastian [1]: git://git.debian.org/kernel/preview/packages/linux-2.6/package.git ============ Introduction ============ The Debian package for the Linux kernel and all related ones are currently maintained by the kernel team in a Subversion repository. This proofed as sometimes no easy way in the meantime. So the decision was made to go for some git-centric source storage. This document describes my proposal of a setup that uses git with submodules. It tries to support as much features of the current setup as possible. Also it tries to support some new development usages that I missed in the past. ============ Repositories ============ The linux-2.6 package is built from several git repositories. This repositories may be reused in other packages, like linux-tools-2.6. In combination, this repositories includes anything to build the Debian kernels and also derived variants. Repository "linux-source.git" ============================= This repository is derived from the upstream linux-2.6 and the upstream stable repositories. It includes all the code for the main kernel themself. Branches are used for the different supported branches and featuresets. While we don't have any featuresets planned for Wheezy for the time beeing, I don't want to loose the support for them. The branches will be named "$featureset/$dist". $featureset is "main" for the default source. $dist is set to "master" for the main development version usually targeted for experimental. Tags are generated automaticaly based on the super-repository. They are called "$featureset/debian/$version". Architecture specific patches will be not supported. TODO * Handling of cleaned orig source Repository "packages/linux-2.6/abi.git" ======================================= This repository provides all ABI related informations. It includes informations about all supported ABIs. Also it contains informations about ABI overrides. No branches except master or tags exists. Repository "packages/linux-2.6/config.git" ========================================== This repository includes the Debian config for the kernel images and the helper packages. This corresponds to the current debian/config directory in the package. One branch may exist for every supported distribution. "master" denotes the main development tree. The contents are loosly coupled with a specific upstream version or patch level of the main source. Tags are generated automaticaly based on the super-repository. They are called "debian/$version". Repository "packages/linux-2.6/infrastructure.git" ================================================== This repository includes the infrastructure used to build the package. This includes scripts for config handling, control templates, maintainer scripts etc. One branch may exist for every supported distribution. The contents are declared mostly independant of the version of the source and the configs. While sometimes config and infrastructure changes have to be done at the same time, often it'll just work. Tags are generated automaticaly based on the super-repository. They are called "debian/$version". Repository "packages/linux-2.6/package.git" =========================================== This repository pulls in the other three repositories as submodules. Layout: Repository "linux-source":: /source/$featureset Repository "infrastructure":: /debian Repository "config":: /config Repository "abi":: /abi Branches are used for different development trees. This includes the trees for stable releases. This allows independant changes for all the supported and unsupported versions. Tags are used for every release of the package. They are called "debian/$version". TODO * tag format, is there a pseudo-standard? ======================= Source package handling ======================= The repository layout is way different from the current source package layout and from the expectations by the Debian world. One nice way to work with that is the "3.0 (custom)"[1] source type of dpkg. This type is special and allows to script the source package generation and call dpkg only with the finished set of files. The produced source package will have a real type, most likely "3.0 (quilt)"[1]. This script would create anything a Debian source package needs. This includes one patch for each stable release, one patch per featureset, the ABI information for the current ABI and some other information. ======================== Advantages and Drawbacks ======================== Every submodule can be individual changed, updated or even replaced. This allows the developer to remix different versions of the parts. Submodules needs to be updated explicitely. Submodules records the exact commit in the parent repository. Every update of this commit list have to be recorded by a seperate commit in the parent repository. Maybe we can have some scripts to make the handling easier. [1]: See dpkg-source(1) -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Attachment:
signature.asc
Description: Digital signature