For everyone who packages kernel trees:
I've had some questions about getting the source for linaro kernel
packaged, and it seems that this is still not straightforward:
Getting the debian package source (i.e., flat tarball) for a binary
kernel is possible, but only if it is a non-superseded version.
Working out which source package you need is non-obvious (You have to
check for installed kernel packages, and guess which source package
you need, based on that. Non-linaro folks may not understand the
difference between the various meta- and real kernel packages and may
get pretty confused along the way.)
Finding the git tree and the relevant commit to reproduce the source
(including that for superseded kernels) is hard or impossible. It
requires guesswork and/or specific knowledge about the way the
relevant team manages their trees. For some platforms, it looks like
there may be no single tree containing the packaged kernel at all, in
which case you would also need more guesswork and/or scripts or help
from the relevant landing team in order actually to reproduce a
release.
Am I correct in these conclusions?
If so, here's a proposal -- I welcome people's comments (and please do
say if any of these problems are actually solved already!):
For every binary kernel package (.deb) publicly released by any linaro
team, including those produced by the platform team and the landing
teams:
1) The source package's control file must contain a Vcs-Git entry
2) The Vcs-Git entry must reference a git tree which contains the
_exact_ source code which appears in the source package.
* Such a tree must exist and must be publicly readable. It does not
have to be on git.linaro.org (though this is the recommended place).
* Referring to git://git.linaro.org/ubuntu/linux-linaro.git is not
acceptable, unless that repo is populated with the real source for
that specific kernel as well as the packaging.
* Manufacturing the source package from the contents of multiple
repositories or branches at source package upload time is not
acceptable, unless the result is also recorded as a tagged commit in
the repository referenced by the Vcs-Git entry in the debian/control
file contained in that same commit. The commit must have full
history: importing tarballs directly into a repository for the purpose
of release tagging is not acceptable.
* Referring to a tree which does not contain the whole contents of
the debian source package (for example, debian/ and other packaging
files/dirs are missing) is not acceptable.
3) Tagging of packaged kernels must be done in a standard way.
* I recommend <source package name>_<package version>, matching the
Source field of debian/control and the version number of the most
recent debian/changelog entry respectively (which must both be present
in the repository as a consequence of (2)). If we want to avoid
namespace pollution, we probably want to add a prefix such as debian/
or ubuntu/ to the tag name to indicate that the tag describes the
source for a published .deb package. If so, we must standardise that
prefix so that it is identical in all out trees.
* Tree maintainers are of course free to add any other additional
tags for their own use if they want to.
All teams already do release tagging of some sort, but the lack of
consistency creates difficulties when anyone from outside the team
tries to understand that team's trees.
* We _could_ standardise the following, but it is not essential:
* ubuntu/<release>: The tagged source for the _original_ kernel
which was distributed in <release> (where <release> is a linaro
monthly release such as 11.12 or 12.01)
4) No specific branch naming requirements exist.
* Release tags do not necessarily need to appear on any branch.
* We _could_ standardise the following, but it is not essential:
* ubuntu/latest - the tagged packaged source for the most recent
kernel release made from this tree
(In the above, we could choose a diferent prefix instead of ubuntu/,
but as described in (3) ,this should be chosen globally and _not_ on a
per-tree basis).
Cheers
---Dave
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
