On Sun, Jun 05, 2005 at 10:26:27PM -0400, Jeremy Katz wrote:
As far as I'm concerned, DKMS solves the wrong problem. As long
as the
user has to have a compiler installed to use it, it's not useful.
You don't have to have a compiler on the target systems. *If* you've
got a compiler, and choose to invoke the build system (either through
AUTOINSTALL="yes" on a per-package basis, or manually), then it yes,
you can use the compiler to build. But it's not strictly required.
Point in fact, Dell's factory install process doesn't invoke the
compiler at all - it uses the precompiled modules from each package.
The build system needs a compiler, the target systems don't.
As long as it's not an integrated part of the packaging system,
it's not useful.
This is mostly true. It would be of great benefit if it were
integrated, but it's not strictly required to be if you've got a
compiler on your target systems, or an ancillary build system.
That said, I think that cleaning up the interaction for kernel
module
packages and ensuring that everything is cleanly defined such that it
can work is a good goal for FC5 and I'm willing to help out some to make
it happen. Spot and I talked briefly about this in New Orleans and I
think the plan is to restart that discussion after he gets back from a
(much needed and deserved) vacation.
Agreed on all points.
Once _that_ is defined, then we can think about buildsystem triggers
to
ensure that the packages get rebuilt in a timely fashion and that the
tree thus stays sane.
Agreed.
--
Matt Domsch
Software Architect
Dell Linux Solutions
linux.dell.com &
www.dell.com/linux
Linux on Dell mailing lists @
http://lists.us.dell.com