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

Re: base-installer smarter kernel selection



On Fri, Feb 13, 2004 at 03:39:02PM -0600, Stephen R Marenka wrote:
> On Fri, Feb 13, 2004 at 08:50:55AM +0100, Sven Luther wrote:
> 
> > I understand your interest in selecting a range of kernels, but this
> > sounds like a hacky way to achieve that. It would be better to notice
> > that a kernel is composed of :
> 
> I won't dispute you. It was quick 'n dirty and it totally solved my
> problem for m68k. It also avoids having to hardcode version numbers
> since some subarchs can and may want to use both 2.4.x and 2.2.x
> kernels (I also think it's bad form to hardcode anything you don't have
> to). Finally, it was pretty non-invasive.
> 
> >   kernel-image (common part)
> >   -
> >   2.4.22 (version number)
> >   -
> >   powerpc (build configuration or flavour)
> >   -
> >   chrp (powerpc subarch boot-loader format)
> > 
> > And do some parsing to detect the version/flavours, which can be
> > intercheangeable, while the subarch flavor is determined by hardware
> > detection. 
> 
> kernel-image and powerpc will be constant in $kernels on your arch by
> definition. As stated, I wanted to avoid the version number. All that's 
> left is the subarch bit (or whatever) on the end. I don't see any 
> reason to bother with parsing anything else.

Nope, i will probably have a kernel-image-2.4.24-power3 and -power4 in
the future.

I guess it would be easier to maybe add a new tag in the Package list,
or better yet, a provide: kernel-image-<subarch>, and then you can parse
on the subarch.

This one, i like. i doubt the arch info is needed, since you will
probably never have kernels of other arches in your package list. By
doing just the above, we can then search for the packages which provide
the right kernel-image, and automatically propose them to the user. 

base-installer would still know about a default kernel, or maybe we can
add some prioritizing into the kernel-image control file. Not sure
though.

> You are of course welcome to improve or replace the code that's there, 
> that's all I did. :-)

Yeah, it is broken right now anyway.

Friendly,

Sven Luther



Reply to: