[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

d-i changes


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

* 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

Reply to: