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

Evangelos Foutras evangelos at foutrelis.com
Sat Aug 6 02:52:43 EDT 2011

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. :)
Version: GnuPG v1.4.11 (GNU/Linux)


More information about the arch-dev-public mailing list