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

Jeremy T. Bouse [c] jbouse at debian.org
Thu Feb 16 17:53:22 UTC 2006


    I've just been trying to catch up with the posts already so figured
I'd just start another thread as it seemed I would address things from
multiple emails. I really need to get my sieve filter script updated to
move the list emails into the proper folder now I guess :)

    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.

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

    Regards,
    Jeremy


--
------------------------ [ SECURITY NOTICE ] ------------------------
To: pkg-xen-devel at lists.alioth.debian.org.
For your security, jbouse at debian.org
digitally signed this message on 16 February 2006 at 17:53:28 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAjhwa2cteGVuLWRldmVsQGxpc3RzLmFsaW90aC5kZWJpYW4ub3JnA
Gpib3VzZUBkZWJpYW4ub3JnAGVtYWlsIGJvZHkAzAcAAHwAfAAAAAEAAAAYvPRDzAcAAF
sDAAIAAgACACBbbe/kx8tpUyJhmgvpubSxgZmn0dxD/KgljpsTpsvZVQEAJLQlVT52rnd
nqox8AzyHB09mthbDWqsaMF1UXyCm8B52Ot2iqqv7oV+1Cv1A2EjeFH4fxk/pRtHuKTx8
w8WdmgQG/yRiU2lnRW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------




More information about the Pkg-xen-devel mailing list