GIT for linux-2.6
Hi folks
This is my proposal for a git-migration for the core Linux packages. I
believe it would work, but I have no implementation yet. It is more
complex than it would be with a fully merged tree, but it allows more
ways of doing development without needing to reinvent the wheel all the
time.
Please comment.
Bastian
============
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 "source"
===================
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 versions. …
Featureset can be included as different branches. While we don't have
any featuresets planned for Wheezy for the time beeing, I don't want to
loose the support for them.
TODO
* Branch names
* Architecture specific patches
Repository "config"
===================
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.
The contents of this repository are loosly coupled with a specific
upstream version or patch level of the main source.
Repository "infrastructure"
===========================
This repository includes the infrastructure used to build the package.
This includes scripts for config handling, control templates, maintainer
scripts etc. The contents of this repository are declared independant of
the version of the source and the configs.
Repository "package"
====================
This repository pulls in the other three repositories as submodules.
Layout:
Repository "source":: /source/$branch
Repository "infrastructure":: /debian
Repository "config":: /config
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. This tag also includes
references to all the commits of the submodules and therefor describes a
complete release without individual tags in all the repos. This allows
the user to retrieve all the informations to generate every version.
=======================
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 patches for every source from the base version. Also it may do
various safety checks like out-to-dateness of the several sources.
========================
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.
A submodule reference does not keep objects alive. So without some extra
care, commits in the submodules may disappear.
[1]: See dpkg-source(1)
--
It would seem that evil retreats when forcibly confronted.
-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
Reply to: