Bug#512968: grub-pc: Fails to install when gnumach is installed

[Robert Millan]

On Tue, Jan 27, 2009 at 02:59:18AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2009-01-25 at 23:49:14 +0100, Robert Millan wrote:
> > On Sun, Jan 25, 2009 at 03:31:37PM +0200, Guillem Jover wrote:
> > > When gnumach is installed grub-pc fails to install due to at least the
> > > missing function make_system_path_relative_to_its_root. Also afterwards
> > > it aborts if it cannot find the needed stuff to successfully boot a Hurd
> > > system, which should not be fatal on non Hurd systems. The attached
> > > patch fixes those problems.
> > > 
> > > For upstream submission you might want to replace the dpkg invokation
> > > with uname.
> 
> > I think I'll just refrain from installing those files on systems where
> > they're not useful.  The generated boot entry is going to be system-specific
> > anyway, so there's no use in providing them.
> 
> Hmm, thinking about it now that makes sense, as those scripts seem to be
> designed to work only for the host system (from the README it says
> 10_* are for native entries). But then the users lose the nicely set
> default entry for other systems, which in the Hurd case is known to be
> painful to get right and/or copy paste from random places.
> 
> Anyway, yes, I guess the best option is to not install non-native 10_*
> scripts, and add support for the Hurd and others into the os-prober one,
> which should be more generic, and be able to handle such cases better.

Yes, for non-native build options os-prober (or custom entry) is the way to
go.  I'm working with upstream to get the file selection merged.

But for Lenny we need a quick solution.  We could just use your patch there.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."