rawhide report: 20050310 changes

[Bill Rugolsky Jr.]

On Fri, Mar 11, 2005 at 11:18:56AM -0600, Jason L Tibbitts III wrote:
> RE> It would require to make the development package a requirement for
> RE> every install.
> 
> Only if you use DKMS as is.  But if you take it as a starting point
> (i.e. what Mr. Rugolsky suggested) and make its output not an
> installed module but a kernel-module-whatever RPM then end users
> wouldn't need the development packages.

The development suite is definitely an issue for lean installs.  Though I
must admit to being somewhat bemused by folks who can install Java,
Python, Perl CPAN, etc., yet think that a C compiler is bloat.  Fedora is,
after all, a free and open source operating system, written primarily
in C!  The "security benefit" of not having a C compiler is a red herring.

Nevertheless, there are valid reasons to not have a development
environment on every host; I have solid-state routers with only 256MB of
flash storage running a stripped-down variant of FC1.  My custom kernel
packages for those machines omits everything under /lib/modules/`uname
-r`/build/. There is no choice but to either build out-of-tree drivers
into the package, or get/build the driver packages from elsewhere (as
I have done for the WAN drivers).  DKMS supports this paradigm with
mktarball/ldtarball, which I'd rather be RPMS, for all the usual
reasons.

In the "usual" lean install, where the kernel package contains the
requisite build tree, one could proxy the compilation/linkage using
something like distcc.  If it works on the Zaurus, it can work for
Fedora! :-)

It is fine to put all sorts of out-of-tree drivers in Fedora Extras or
some other repository, and it would be nice if those repositories built
binary drivers for each "official" kernel.  But what about kernels in
testing, Rawhide, Dave Jones's personal ftp directory, Arjan's -ac RPMS,
and self-built kernels?

Fedora is not RHEL.  If we want folks to test new kernel releases
[cf. LKML "RFD: Kernel release numbering" discussion], we need to
lower the barrier to doing so, even if that enables the user to shoot
himself with a bazooka.

The problem with just dropping DKMS and similar solutions into the
existing automated infrastructure is that failures are not captured
adequately by the package dependency solver logic.  If failures occur,
they are not readily detected, and then one has a kernel installed that
may have a broken configuration.

Hooking /sbin/new-kernel-pkg to install driver module RPMS presents the
problem that if dependencies are determined dynamically by a scriptlet,
there is no mechanism to communicate that to the top-level
package manager (in order to retrieve the packages, if necessary), or
to insert them into an RPM transaction.

It's unclear to me whether it is possible or kosher to initiate a new
transaction from a post-install scriptlet, and whether that would confuse
all of the package managers.  In any case, there is no robust mechanism
for dealing with failures.

/sbin/new-kernel-pkg should not be building an initramfs and updating the
bootloader configuration unless the locally-defined module dependencies are
satisfied.

But how to structure the control flow is unclear.  My preferred solution
would be a generic extension to the package managers that simply allows
some packages to be built from source as part of a multi-transaction
update.  The build script needs some mechanism to call back into the
package manager in order to satisfy additional build dependencies, etc.
Unfortunately, the end result is probably something akin to the various
automated build environments.  Perhaps something less bloated is sufficient
for the special case of kernel, though many free software architectures
support third-party plugins, and it would be useful to solve the problem
once.

Then again, perhaps this is all outside of the scope of the Fedora Project,
and should remain a feature of source-orient package management systems
like Portage.

Regards,

    Bill Rugolsky