Hello Thomas,
On Sun, Jul 04, 2004 at 01:37:47PM +0200, Thomas Vander Stichele wrote:
> On Mon, 2004-06-28 at 12:58, Axel Thimm wrote:
> > On Mon, Jun 28, 2004 at 12:40:22PM +0200, Arjan van de Ven wrote:
> > > actually it 100% is. kernel-devel, if it ever comes to a
> > > reasonable thing, will be in *addition* to what is there right
> > > now not as replacement.
> >
> > Maintaining two solutions for the same problem? It is per
> > definition error-prone and predestined that one of them will
> > deteriorate over time.
>
> I'd like this situation resolved just as much as you do, but I'm not
> always following what you're trying to say.
>
> Please let's keep it constructive. Which "two solutions" are you saying
> Arjan is hinting at ? AFAICT he means something that is installed "on
> top of" the current kernel stuff.
>
> You make a blanket statement shrouded in mystery then based on that
> preposition make a true, but irrelevant, broad sweeping statement. The
> point should be made on the truthfulness of the assumption, not the
> result :)
you are jumping quite late into this thread, so you may be missing the
more detailed discussions on the different propositions made. There is
no mystery or blanket statement.
The two solutions are the one that is already in place in recent
kernels, as well as a new kernel-devel package as discussed by
Arjan. No mystery involved, and indeed two solutions for the same
problem ("how to build kernel modules for a given kernel").
I'd like one solution as proposed on anothe post in the thread, that
would place the bits required to develop kernel modules in unique
folder names, say under /usr/src/. Unique in the sense that the
required bits for different archs should not overlap like they do now
for i686 vs i586 vs x86_64 etc.
So in order to salvage the current model of bundled kernel and kernel
headers one would have to uniqify the kernel `uname -r` to avoid
clashes of /lib/modules/`uname -r`/build. I'd prefer not to salvage
this model, but to have a clean separation of kernel and kernel
headers.
Anyway, as quoted in another post, this discussion was one of the
endless ones w/o results, so packagers will just have to find their
own way of dealing with it, just as we have been doing for the last
years ... :(
--
Axel.Thimm at ATrpms.net
Attachment:
pgpOPI6KxTVRY.pgp
Description: PGP signature
