Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote:
> On Wed, Apr 25, 2001 at 08:54:33AM -0400, Dale Scheetz wrote:
> > On Wed, 25 Apr 2001, Herbert Xu wrote:
> >
> > > That is the raison d'etre for kernel-headers. However, the new per-image
> > > kernel-headers exist solely for the benefit of module builders.
> >
> > Then you break things for no good reason. These "module builders" you
> > speak of should be using the same headers as glibc.
>
> Hmm, I think you better refresh your theory about kernel modules.
Right back at you...
>
> > > Huh? There is still a kernel-headers package for the glibc maintainer to
> > > use. In fact, it's exactly the same as before.
> >
> > And when some other library gets built with one of your other headers?
>
> Which other library uses kernel headers? They better stop or they probably
> won't compile at all with 2.4.
This doesn't reduce the damage hole you are creating.
>
> > This is the sole reason for the existance of kernel-headers. Your
> > continued insistance that doing something else is good for someone else
> > ignores these reasons and is fundamentally a broken concept.
>
> Dale, I expected you to have a better understanding of this since you
> used to maintain glibc. It is true that the plain kernel-headers exist
> solely/mainly for the purpose of building glibc. However, it has nothing
> to do with the new flavoured kernel-headers. These should/will not be
> used to build glibc. They exist so that kernel modules with correct
> checksums can be easily built.
Well, first of all, my contribution to glibc development was that of the
little boy with his finger in the dyke trying to stem the oncoming tide.
I held the package after David dropped it, until Joel took it over.
None of this is relevant to the current discussion.
Please explain to me just how multiple header packages makes additional
module creation more safe/useful/correct. Most of the third party module
vendors (like VMware for instance) generate their needed modules at
installation time, against the kernel source on the target machine.
If all of this effort and bother is to make third party, binary only,
module provider's lives better, I don't see how this accomplishes that.
You give more than one choice and my karma provides the most wrong one in
the group.
You continue to demand good reasons not to do what you want, and ignoring
all reasons provided. My question is: "Just how does this bloat improve
the packages in main?" That is our goal, and supporting the needs of
proprietary vendors in this fashion doesn't help those users who "need"
non-free software.
Until you can answer my question reasonably, I will continue to be opposed
to your proposal.
Luck,
Dwarf
--
_-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_-
_- _-
_- aka Dale Scheetz Phone: 1 (850) 656-9769 _-
_- Flexible Software 11000 McCrackin Road _-
_- e-mail: dwarf@polaris.net Tallahassee, FL 32308 _-
_- _-
_-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_-
available at: http://www.polaris.net/~dwarf/
Reply to: