Re: release notes: questions about some recent changes
On 9 November 2010 17:20, Julien Cristau <jcristau@debian.org> wrote:
> Hi Javier,
>
> I have some comments/questions on recent changes to r-n svn:
> - r7732: why talk about vol_id and blkid? lenny's e2fsprogs has blkid,
> so the mention of vol_id seems superfluous
I thought we need to talk about both because users could change to
using UUIDs *before* the upgrade. Reading bug reports I came to
believe that vold_id was not available in lenny's e2fsprogs. I believe
I did some testing in a VM to this effect.
If it's there then we could drop it, the goal of the information was
to facilitate the change before the upgrade.
> - r7734 talks about a kernel upgrade, which seems irrelevant
That's true, the only upgrade needed for this would be e2fsprogrs.
Could be removed, or e2fsprogrs could be explectely mentioned if it is
indeed required. (see above).
> - r7735 says 'default kernel in lenny', but the change actually uses the
> kernel version from squeeze. Which is it?
Commit log is wrong, it should be squeeze's
> - r7736 doesn't seem useful?
Well, it was requested in some bug report. It doesn't hurt.
> - r7737 should probably be i386 and amd64 only, since that's the only
> archs with grub in lenny
It's currently 'fixme' so it's not printed out. In any case you are
right, I will change that.
> - I don't understand the TODO in the upgrading-udev section. The
> preinst check was specifically changed to display a debconf screen
> instead of aborting, what more needs to be tested?
I wanted to test it out in a VM to see the actual behaviour just to
ensure that we are proposing something same. If the upgrade of the
kenel+udev (jointly, not in two steps) prevents the debconf prompt it
might be better to suggest that instead of suggesting first kernel and
then udev.
> - r7744 suggests downgrading udev, but that won't be possible after
> upgrading the rest of userspace, so I'm not sure how useful that
> suggestion is
Since we are suggesting first an upgrade of the kernel+udev+reboot
before the full upgrade I think a downgrade is possible, since most of
userspace is not yet installed.
The steps currently are:
1.- upgrade the kernel and udev
2.- reboot
3.- do full upgrade
We recommend the following for sytems tight on space or when a lot of
packages might be removed:
1.- minimal upgrade
2.- upgrade the kernel and udev
3.- reboot
4.- do full upgrade
The first one allows for the downgrade, although I'm not so sure about
the second one. I would need to test it out.
Regars
Javier
Reply to: