Re: SEUL: Proposition for a simplified kernel recompiling proced

[jfm2@club-internet.fr]

> 
> 
> On 04-Feb-98 George Bonser wrote:
> -> In my opinion, yes. Because the same script could be used to install an 
> -> updated kernel image file that we might want to ship to users if you give
> -> it a different option.
> 
> Wouldn't dpkg handle this with or without make-kpkg?
> 
> -> WIth one option it would install a given kernel image with another option
> -> it would make and install one.  Besides, if you look at make-kpkg, it is
> -> pretty powerful.  Sure, we could write a replacement that does everything
> -> that it does but we do not have to. There is a perfectly workable, tested,
> -> known good program already in existance.  Why reinvent another wheel.
> -> Also, if it lacks a feature we need, it is far better for the entire linux
> -> community to improve an existing tool than to further fragment linux by
> -> creating yet another that for the most part, duplicates one already in
> -> existance.
> 
> This is just adding overhead.  This make-kpkg, used as you are suggesting, is
> reinventing the wheel, and adding overhead to it.  On top of this we would have
> to create a script to go looking for outdated kpkg's  to delete, the user has
> to be asked about it, he doesn't know.  Before long he's using up many MB's of
> his hard disk for these kpkg's.
> 
> In my opinion we should use it as a model to make sure the right thing is done,
> without adding the overhead of creating a deb pkg and installing it.  Although
> I still feel a 2-4 line script could do the same thing without the added
> overhead.
> 
> And a simple addition to lilo can reboot an old kernel.  The current "make
> zlilo" already renames the old kernel when it's replaced.  We would only have
> to add it to the lilo.conf file as a backup entry.
> 


I think this discusssion I started is devaiting in trivial issues of
kpkg versus make.  Of course better improve the compiling itself but
that is not the point.

The important is than xconfig asks too many questions, is far too
technical for many people and gives the user too many opprtunities to
hang himself.  We must find a way for asking far less questions and
that can involve a change in the file formats (more about this later)
so we must find a way for keeping in sync with the official versions.

I remember than the proposal was: -assume than the kernel will running
on the same box, we can deduce a lot of things from /proc and /etc.
No need to ask about features than we can deduce or faetaures it is
absurd to ask about like ELF support in a contemporary distribution.
-If the feature is not needed for booting and we cannot deduce build
it as a module without asking if possible.  6we also have to install
the kernel, modules, take care of lilo AND INSURE THAN THE DEFAULT
KERNEL IS KEPT AS A SAFEY NET with its own module directory.


About the change in file formats we must introduce the notion of
deduced and forced answer in addition to the Y/N/M than are in the
Linux kernel config files.  AT least at the beginning we wil have to
maintain an additional file in addition of the regular files needed by
the regular Linux config procedures.

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================