[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!



On Wed, Jun 23, 2004 at 11:00:24PM -0500, Manoj Srivastava wrote:
> On Wed, 23 Jun 2004 08:04:11 +0200, Sven Luther <sven.luther@wanadoo.fr> said: 
> 
> >   How should we handle this if there was already a user set
> >   postinst_hook ? This has no chance of working, right ?
> 
> 	Hmm. At the moment, no.

Ok, let's do it the other way then.

> > So, probably, the best solution would be to do it the right way, and
> > have the kernel-package provided postinst do the right thing and
> > detect the bootloader setup at installation time, and not at build
> > time.  
> 
> 	If we can find a way of doing this in a generic manner, so
>  that I do not have to insert and update subarch specific code into
>  the postinst, I'm game. I definitely do not want to have arch
>  specific code all over.

Mmm, from me reading the code, i had the impression that at least some
code is needed in the postinst scripts. Not sure though as perl is
somewhat obscure for me still. What i see is that the postinst script do
some checking for certain bootloaders, and have some special cases for
some of them, i didn't detect the place where the bootloader is called
(as for yaboot and co, it is mentioned -> don't need to do anything).

> 	For example, if the boot loader is 'guess', I can invoke
>  /sbin/guess-loader to determine the boot loader. For official kernel

Ok. That sounds like what we want. I wanted to use powerpc-bootloader
for that, so if i move this script to /sbin/powerpc-bootloader, and
modify the rules file to use this for each powerpc arch, then it should
be all the modification that is needed from kernel-package, right ? 

The only question i have with regard to that are the loaderdep, which
would need to be set to this powerpc-bootloader, and the loaderdoc,
which i wasn't able to understand how they work. In anycase, if my
impression that the loaderdoc copies some kind of bootloader
documentation to the package, this is not going to work with this new
solution.

And in anycase, please change chrp-rs6k to use yaboot instead of quik,
and chrp and prep to use noloader instead of quik.

>  images, I can look to an env var or something to set the bootloader
>  to guess -- and this method shall be available to all architectures
>  to use, if they so desire.

Mmm. I am not sure about this. I would do this also for official images,
since this is especially important for official images, which are built
on one subarch, and need to run on all of them.

Maybe we could modify kernel-package, so that loader is set to
$arch-guess-loader or something, and if /sbin/$arch-guess-loader exists
run it, and do nothing if not. Not sure though. I don't know if it is a
good idea to have a guess-loader providing package for all arches, ...

Mmm, maybe just have it set to guess, and the loaderdep to
$arch-bootloader or something such, which will contain
/sbin/guess-loader, and use some debconf and archdetect magic to help
the user set it if there are various bootloader choices. This sounds
like a more multi-arch friendly solution. I don't know what to do about
loaderdoc though, but maybe it could be replaced by some generic stuff ? 

Friendly,

Sven Luther



Reply to: