Re: [PATCH] prevent duplicated entries due to symlinks

[Pavel Roskin <proski@gnu.org>]

On Mon, 2009-05-04 at 18:45 +0200, Andreas wrote:
> Pavel Roskin schrieb:
> > The result will be that we would have an entry without version instead
> > of an entry with a version.  That's hardly an improvement.  Can you give
> > an example where it would be useful?
> >   
> You have a symlink named /boot/vmlinuz which points at the current 
> kernel version. Now you could of course find out which kernel version 
> it's pointing at but that version could change anytime.

I see, you want to support loading the "default" kernel, i.e. the one
pointed to by the symlink.  This way, re-running grub-mkconfig won't be
necessary if a new kernel is installed.

>  /boot/vmlinu[zx] 
> and /vmlinu[zx] (there should only exist one of them) are the only cases 
> I can think of which have no version in their name. So you always know 
> that the version-free entry always boots the kernel pointed at by 
> /boot/vmlinuz, which is always the current kernel if your distro 
> maintains the symlink. I see no regression there.

Suppose I have Linux 2.6.29 and 2.6.28.  Your script makes entries for
"Linux default" and "Linux 2.6.28".  Then I install Linux 2.6.30 and
don't run grub-mkconfig.  Then I can boot Linux 2.6.30 and 2.6.28 form
the menu, but not 2.6.29.

Even if I run grub-mkconfig, there is still something I lose.  By
selecting "Linux default" I still don't know it it's Linux 2.6.30 or
something else.

For me, the convenience of not having to rerun grub-mkconfig doesn't
outweigh the convenience of knowing what I'm loading.

I know, it's have to argue about preferences, but if you want you
changes to be accepted, you need to present a good case.

I would consider placing the kernel pointed to by the vmlinuz link to
the first position of the Linux kernels.  Another approach would be to
have an entry for the link without suppressing any versioned entries.

> > Please specify where those names are used.  Can you give the
> > distribution name and version where such names are used?
> >   
> Zenwalk, Slackware for example. I think more Slackware derivates are 
> using it too.

Let's add support for more versioned names first.  That should be rather
non-controversial.

> > What is initrd.splash?  Why does it need to be handled like initrd and
> > why is it always version independent?  Again, where is it used?
> >
> >   
> initrd.splash is used by Zenwalk (others too) it contains only the data 
> of one or multiple bootsplashes as returned by the "splash" command. 
> It's used by bootsplash and doesn't contain any files, modules, etc.
> The version independence is quite self-explaining now, I think. Unless 
> bootsplash support was removed it works for any kernel version. And even 
> if bootsplash support is removed it does no harm to load it.
> 
> Is it understandable now?

It's quite strange that some distro would use the initrd functionality
purely for eye candy.  But if that's true, I'm fine with using
initrd.splash as the last resort if no other initrd image is found.

-- 
Regards,
Pavel Roskin