On 18 Sep 2005 03:05:32 +0200, Krzysztof Halasa <[email protected]> wrote:
> Jesper Juhl <[email protected]> writes:
>
> > What exactely is it you want to make a sepperate package?
>
> Just the menuconfig (mconf) at first. OTOH it might make sense to
> move them all.
>
And if you do that, then you'd be shipping a kernel source that it
would be impossible for users to configure without installing
sepperate tools - and tools (unlike for example gcc) that very few
people would have a need for outside configuring their kernel.
Not a good idea in my oppinion.
> > menuconfig is just a little bit of the kbuild system which also
> > includes xconfig, config, gconfig, oldconfig, etc. menuconfig is just
> > a dialog based frontend to the kbuild system which consists of
> > configuration options, help texts, dependency info etc.
>
> Sure, that's what I mean. It's used for configuring the kernel, but
> other packages use it (well, some version) too. Example: busybox.
>
> There is no much point in keeping more than one copy. They are
> completely independent of the kernel, all the kernel wants is to pass
I think there's a point; the kernel source should contain its own
configuration tools.
Just think of how many users would complain that "the kernel is
broken, I can't configure it" and similar. Also, what would ensure
that the config/build tools would always stay in sync with other
kernel changes? Right now things stay in sync since everyone are
using the same version of the tools that ship with any given kernel
and if something breaks it's fixed up along with everything else. Move
it out of the kernel tree and you'll end up having users trying to use
old tools to build a new kernel (or new tools to build an old kernel)
and there's bound to be breakage at some point - why have those extra
problems?
> them some Kconfig file and expect data in .config. (oldconfig uses
> .config.old).
>
if you extract a fresh kernel source and copy your old .config to
.config in the new kernel source dir, then "make oldconfig" will read
that .config and write a new one as well...
> There is a question about config language and possible future changes.
> Not a serious problem IMHO.
>
I disagree.
> > I don't think it makes much sense to split the parts of kbuild that
> > make up menuconfig out into a standalone thing. kbuild (and thus
> > menuconfig) has little use outside the kernel.
>
> It's not exactly the case.
If someone wants to use the tools outside the kernel, then let them
fork off a version and maintain that out-of tree. The in-kernel and
out-of-kernel could borrow code and fixes from eachother if
needed/wanted, but I personally believe there needs to be a version
shipping as part of the source tree.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |