[arch-dev-public] kernel26 -> linux move compat symlinks
It seems somebody (Evangelos, Tobias, who else?) completely misunderstood the "compat symlink" idea for a smooth upgrade path. 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). 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) 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. 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. 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 Please take this into consideration. Regards Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.
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.
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.
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.
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.
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. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOPOS7AAoJEFHosUipmZw0N84H/0MCav8iVuDpc6wO9oEjnOIn uRJFP/JpQjvPc/mgzgu8Flp2FM8GvzEh62oFLYjpV8calzdTRSG9uZLuxpjferSS /+VMIG6zpd31r5rxmIFHb6KxZvFVOf47LawVDhfU5E2xL6ZzOjicEyxsxY1Non8l /fxMWUe3tfVDSgAV6pmp33r0NR6F/OzzC4av1huVDtx/NAPJ4T70btBUCZU/4WTG VaD5JiTrEoTUdKe2a8n6g88FDhbjWB9RAUT9sXoYAK9PdCx6O18d3Y7FBFlTUlvQ i4cg3gHEvcYo69t3d5PDS9EBX384dzA9qJDwQXyinxTuPWTbUm1L12Hw4XPl6HI= =KlwK -----END PGP SIGNATURE-----
On 06/08/11 09:52, Evangelos Foutras wrote: [..] Sorry for the "OMG BEGIN PGP SIGNED MESSAGE" noise; I now have PGP/MIME enabled by default so any future signatures should come as attachments and not inline.
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.
On 6 August 2011 17:19, Thomas Bächler <thomas@archlinux.org> wrote:
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.
I've been testing the upgrade path in a couple of ways (both stock and a custom one) and I have to fully agree here with Thomas and his changes. -- GPG/PGP ID: 8AADBB10
On 06.08.2011 11:53, Ray Rashif wrote:
On 6 August 2011 17:19, Thomas Bächler <thomas@archlinux.org> wrote:
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.
I've been testing the upgrade path in a couple of ways (both stock and a custom one) and I have to fully agree here with Thomas and his changes.
Assuming it work as described +1 from me too. -- Florian Pritz
participants (4)
-
Evangelos Foutras
-
Florian Pritz
-
Ray Rashif
-
Thomas Bächler