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

[Evangelos Foutras]

-----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-----