FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 08-05-2011, 12:54 PM
Thomas Bächler
 
Default 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
 
Old 08-06-2011, 06:52 AM
Evangelos Foutras
 
Default kernel26 -> linux move compat symlinks

-----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
/+VMIG6zpd31r5rxmIFHb6KxZvFVOf47LawVDhfU5E2xL6ZzOji cEyxsxY1Non8l
/fxMWUe3tfVDSgAV6pmp33r0NR6F/OzzC4av1huVDtx/NAPJ4T70btBUCZU/4WTG
VaD5JiTrEoTUdKe2a8n6g88FDhbjWB9RAUT9sXoYAK9PdCx6O1 8d3Y7FBFlTUlvQ
i4cg3gHEvcYo69t3d5PDS9EBX384dzA9qJDwQXyinxTuPWTbUm 1L12Hw4XPl6HI=
=KlwK
-----END PGP SIGNATURE-----
 
Old 08-06-2011, 07:17 AM
Evangelos Foutras
 
Default kernel26 -> linux move compat symlinks

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.
 
Old 08-06-2011, 09:07 AM
Thomas Bächler
 
Default kernel26 -> linux move compat symlinks

Am 05.08.2011 22:23, schrieb Heiko Baums:
> Am Fri, 05 Aug 2011 14:54:07 +0200
> schrieb Thomas Bächler <thomas@archlinux.org>:
>
>> 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.
>
> Wouldn't it be better to put it to post_upgrade instead of post_install?

What would be the point?
 
Old 08-06-2011, 09:19 AM
Thomas Bächler
 
Default kernel26 -> linux move compat symlinks

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.
 
Old 08-06-2011, 09:53 AM
Ray Rashif
 
Default kernel26 -> linux move compat symlinks

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
 
Old 08-06-2011, 01:49 PM
Florian Pritz
 
Default kernel26 -> linux move compat symlinks

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
 
Old 08-06-2011, 02:56 PM
cantabile
 
Default kernel26 -> linux move compat symlinks

On 08/06/2011 12:19 PM, Thomas Bächler wrote:

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.


Excellent idea.

Users are expected to read pacman's output anyway (or suffer the
consequences).

--
cantabile

"Jayne is a girl's name." -- River
 
Old 08-06-2011, 04:23 PM
Heiko Baums
 
Default kernel26 -> linux move compat symlinks

Am Sat, 06 Aug 2011 11:07:17 +0200
schrieb Thomas Bächler <thomas@archlinux.org>:

> What would be the point?

Well, nothing. I have to admit that I made a small error in reasoning.
I just didn't thought about the change of the package name. ;-)

Heiko
 

Thread Tools




All times are GMT. The time now is 10:01 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org