[arch-dev-public] kernel26 -> linux move compat symlinks

[Thomas Bächler]

Am 06.08.2011 08:52, schrieb Evangelos Foutras:
> On 05/08/11 15:54, Thomas Bächler wrote:
>> It seems somebody (Evangelos, Tobias, who else?) completely 
>> misunderstood the "compat symlink" idea for a smooth upgrade path.
> 
> Compatibility is retained in a consistent way; all systems end up with
> the same files installed under /boot. The implementation is pretty
> straightforward as well.

You retain compatibility by adding completely redundant links that make
no sense on fresh installations and serve to confuse people.

What I want to provide is a mostly clean way of having the symlinks when
you replace kernel26 with linux, but not having them when installing linux.

>> 1) The symlinks are only there for a smooth upgrade path, and NOT 
>> supposed to be a part of the package. The user is supposed to be
>> able to delete them after adjusting the bootloader (so, the link
>> should not reappear after every update, like it does right now).
> 
> Three symbolic links are nothing to get hung about.

They are.

>> Right now, the PKGBUILD says # add compat symlink for the kernel
>> image ln -sf vmlinuz-${pkgname}
>> "${pkgdir}/boot/vmlinuz26${_kernelname}" but this is supposed to be
>> in post_install only.
> 
>> (If we change this now, the compat symlink will be missing on a
>> 3.0-2 -> 3.0.1-1 update, but we will have a clean update path for
>> the 'core' users, which is all that matters)
> 
> I don't think that's a proper attitude towards people that help QA
> packages by having [testing] enabled. Upgrading from any previous
> package version – regardless of which official repository it has existed
> in – needs to be supported.

It is. It can be very hard to provide smooth upgrade paths, and you
don't always get it right the first time. Providing smooth upgrade paths
from the broken package to the fixed package is sometimes impossible,
but once you get it right, you move it to core. People who use testing
are _expected_ to be up to date on such changes that will break their
system.

(If you talk about "proper attitude", let's talk about libreoffice: Andy
provided us with a broken update path AND a broken installation path,
then went to vacation.)

>> 2) All this makes no sense for custom kernels, it is only for "our" 
>> kernels, so that we don't have tons of reports of unbootable systems.
>> Thus, the compat symlink part of post_install should be made such
>> that custom kernel users never execute it.
> 
> Similar to above, you're suggesting to remove functionality you don't
> find important but might be useful to other people/packagers.

I am suggesting not to provide redundant functionality. Let me explain
to you why the links are there: There are users who don't always read
the news, update their system, and end up with broken bootloader paths
after the package replacement. Without these links, these users would
give us an endless stream of bug reports and ml/forum posts. People who
build their own custom kernels from our PKGBUILD will be aware of the
change and adjust their bootloader, thus will not cause us trouble.

>> 3) As it is now, new installations will end up with compat symlinks. 
>> This is only supposed to be for updates, not for new installations.
> 
> See my first point about being consistent. The symbolic links to the
> initramfs images would have been part of the package as well, but they
> conflicted with the untracked images created by the kernel26 package,
> and thus were moved to the .install script.

See my last point about what the links are for. They are not supposed to
be permanent, they are to smooth a transition for users. The user is
supposed to be able to get rid of them at a time of his choosing.

If we put them into the package, when do we remove them? In a month? In
a year? Never (and thus have /boot cluttered with file names that serve
to confuse new people with fresh installations)?

>> For this, I originally suggested the following to Tobias (for 
>> post_install):
> 
>> loaders="$(find /boot -name syslinux.cfg -or -name extlinux.conf -or 
>> -name grub.cfg -or -name menu.lst)" [ -f /etc/lilo.conf ] &&
>> loaders="$loaders /etc/lilo.conf" if [ -n "${loaders}" ] && grep -q
>> -e vmlinuz26 -e kernel26.img -e kernel26-fallback.img $loaders; then 
>> # compat symlinks ln blablabla fi
> 
> That doesn't look very KISS to me, compared to the current
> implementation. Therefore, I'm respectfully against it. :)

It may look complicated, but it is the right thing to do. Provide
backward compatibility for those who need it, and don't clutter the
system with legacy stuff for others.

If you want it to be KISS, let's not provide any backward compatibility
and add an install message telling people to change their bootloader.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20110806/91b0d487/attachment.asc>