Hi again, After a report of yet another instance of un-findable source for a kernel released from a landing team, it would be good if we could move forward with this.
Does anyone have any significant disagreements with the proposal below? If not, I can try to write up a formal specification somewhere. Can we then plan to implement it? If anyone has any preference for the common prefix for tag names, please speak up (otherwise we will proceed with the "ubuntu/" prefix). Cheers ---Dave On Fri, Jan 13, 2012 at 01:32:35PM +0000, Dave Martin wrote: > 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. Note: this means that the released binary packages must be reproducible from the tagged source using standard package build mechanisms, to the extent that the exact versions of build tools and other build-time dependencies used to build the originally released binaries are still avilable. > > > 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
