Hi,
as far as I understood those are the changes planned for d-i
(Otavio, please correct me where I'm wrong):
* d-i will use sid as a development platform:
- d-i in unstable will use unstable as its udeb source,
instead of testing which is the case today
- It will be binNMUed on all architectures if a script determines
that the initrd on one needs to be rebuilt, because there are
changes in the packages built into the initrd. It will not
just be binNMUed daily. However they will try to get the
same binNMU versions on all architectures, hence the binNMUs
on all (global version).
- This will possibly be prepared in experimental.
* In the beginning of these changes the dailies will keep running as
usual. It's planned to move the dailies to the sid build of
debian-installer as soon as it's feasible. d-i releases will use
testing.
* For bleeding edge features (like WPA in netcfg) and to test
development kernels (i.e. RC kernels prepared in experimental),
experimental will be used. This will happen after the sid work is
done at the earliest. There will be daily builds against this,
too. They won't be advertised and solely be for development of
debian-installer. For this to work there need to be kernel udebs
for experimental, too; with some relaxed checking if any module is
new or in multiple packages (which then needs fixing before the
upload to sid).
* For testing migration we'd start off moving it to testing manually,
as before. In the future we need to solve two things:
- GPL compliance: If d-i starts to use Built-Using, it should be
safe from a compliance point of view. I don't know what happens
if you refer a package that is no longer in the pool. I presume
it'd get rejected. I don't know how painful that would be or
if we need to up stayofexecution time. (Possibly not because
we've got autosigning now, but I don't know.)
- Dependencies: The udebs need to grow proper dependencies. In
general that just needs doing. There are two sub-points apart
from getting the usual dependencies:
+ Which packages should migrate when debian-installer does?
I think we want every package that's in the initrd to be at
least of that version in testing. (No strict dependencies,
but bigger or equal.) That should ensure that we don't block
security updates, testing fixes and the like and also ensure
a common baseline. This could be done by adding a special
binary package that depends on all the udebs used by the initrd.
+ All virtual packages that are provided by udebs on an
architecture need to be migrated at once. Other udebs using
them might use alternatives, but it's not enough if only one
of them migrates. (Technically they are even alternatives,
because they provide the same file paths.) This might require
adjustments to britney.
* Later on d-i should be fixed not to have the Linux kernel and ABI
version hardcoded. This is not currently considered critical
because it does not happen too often. Some solution needs to be
found that provides d-i with the right version to use (without the
kernel flavour).
So the steps seem to be:
1. Get d-i to build against unstable.
In parallel: Get the kernel udebs to be built from the regular
linux-2.6 source. This is expected to be quite a bunch of work
with quite some corner cases to be ironed out.
2. Get d-i to build against experimental.
In parallel: Fix up the CD images to take d-i from sid.
3. Sort out the dependencies for britney etc.
This is really intended as the last step. Let's hope we get there
for wheezy.
At that point Otavio will still check the results until we're
confident that testing migration is working like we want it to.
4. Profit and get rid of d-i releases and just handle d-i like any
other package.
Kind regards
Philipp Kern
Attachment:
signature.asc
Description: Digital signature