[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

GIT for linux-2.6, take 2

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.


[1]: git://git.debian.org/kernel/preview/packages/linux-2.6/package.git

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.

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

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.

* 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.

 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

* 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

Reply to: