[Pkg-xen-devel] Debian revisions and policy comments [signed]

[Guido Trotter]

On Thu, Feb 16, 2006 at 09:53:22AM -0800, Jeremy T. Bouse [c] wrote:

Hi,

>     We can play with the revision of the packaging during testing. One
> idea would be to use 3.0.1-0.YYYYMMDD for experimental test packaging
> and then later change to 3.0.1-1 for the actual release. The advantage
> of this is that it gives us an indefinate amount of revisions without
> making the version string considerably longer with multiple versions. Of
> course it would limit us to a daily build release. We also need not have
> to necessarially upload to the 'experimental' distro for testing but can
> host a mini-repository using the mini-dinstall package and even have it
> so anyone in the group could actually upload to that, whereas the
> official upload would need to be done by one of us with DD upload rights.
> 

Having a mini-dinstall repo is fine... I can provide one under debian.quaqua.net
if you like! As for the versioning... Since we don't want to confuse with NMUs
maybe it's better if we avoid the "." in the debian part...

Also, even if we have our private mini-dinstall repo every time we upload there
we need to bump up the version, as we would do with experimental, in order to
let people upgrade, but what about the changlog entry? Would every entry be
official only for debian uploads? In that case we can just do something like
3.0.1-0+internal_number bumping up internal_number whenever ones like, and then
changing the first one when we do debian uploads... And the internal number will
always be shorter than YYYYMMDD and also grant us more than one upload a day!

>     As for the kernel patch build policy. As I've spoken with a few
> other DDs, the build should be self-contained and this not require
> anything beyond what is listed in the Build-Depends in order to build
> properly. The idea being a blackbox build that only downloads what's
> listed in the Build-Depends and builds offline. With that the use of the
> upstream build process using wget to download the kernel doesn't fit
> well. 

True... Well, let's avoid that, then!

> Unfortunately Debian only provides one kernel source package and
> it isn't exactly the same version in stable, testing and unstable so
> this is a bit of a quandry to work out as we need to provide a patch. 

And also xen doesn't support the last one debian-stable has, but an older one...

> as someone stated this would be a lot easier if it were merged with the
> mainstream kernel, but that may take some time so we need to come up with the
> most elegant way that fits the distribution. I hadn't taken much of a look yet
> to see what the patches actually did but noticed that the patches were applied
> before the sparse tree during the patch creation process. Would it potentially
> be possible for us to manage multiple kernel version patches to be applied
> before the sparse tree in order to match the versions available within the
> distribution? 

The first point is: do we want to support anything different than 2.6.12.6,
which is the one xen 3.0.1 supports officially? If we do then I guess we're in
trouble because of the fact that patches might not apply, etc!

> Granted this would add extra effort into making the build. Obviously having
> upstream just providing kernel-<version>.patch files would be better than
> having to generate the patch during build process, but that may take even more
> time to coordinate.
> 

On the other hand if we just support 2.6.12.6 we can just ship
kernel-2.6.12.6.patch prepared manually in the debian/ directory and forget
about it...

Guido