Re: removing 2.4 from etch/sid

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, May 18, 2006 at 12:26:40AM +0200, Frans Pop wrote:
> On Wednesday 17 May 2006 20:53, Sven Luther wrote:
> > We have metapackages in place, which i believe will take charge of
> > upgrading from the 2.4 to the chosen etch 2.6 kernel. This, as any
> > kernel upgrade, will need a reboot, which is not without risk, but
> > which we should hopefully have ironed out all the major problems by the
> > time of the etch release, so it should be made to be painless (or
> > documented in the release notes).
> 
> Upgrading from 2.4 to 2.6 is absolutely not trivial in a lot of cases. See 
> the Sarge release notes for some potential issues users may face.

Ok, i have read the sarge release notes, an i thus propose the following plan
for etch :

  1) we create a new package, linux-compatibility, which would be pre-depended
  on by the linux-image packages, and which would provide a predepend script,
  /etc/kernel/predepend.d/compatibility.

  2) this pre-depend script will examine from what kernel we are upgrading
  (what kernel we are running, discovered by uname), what arch/subarch we are
  on, and based on that, make sure any number of known upgrade problems are
  respected. This will not fix all the cases, but new problems can be filed
  as bug reports against this package.

  3) Since it is a pre-depend, we can inform the user about the issues, and
  even propose some automated fixes for the most common issues. We can also
  make sure to not call <bootloader>-update if the upgrade still is known to
  be breaking, after informing the user.

  4) This would mean maintaining a mapping of name-changed modules and
  searching /etc/modules for them, detecting a lvm1 scenario, check for the
  presence of a sata controller, and propose the /dev/hda -> /dev/sda changes,
  keyboard and mouse configuration. I am not sure alsa warrants a pre-depend
  fix, but we can inform the user of this issue.

We use bugs against these packages to mass-test upgrade from sarge during the
freeze phase, and complete this upgade package.

So, it may not be trivial, but right now the issues are documented in the
release notes, this would allow to either fix them during the upgrade, or at
least include the documentation in the packages themselves, as not everyone
reads release notes.

What do you think about this plan ?

Friendly,

Sven Luther