Unnanounced migration phase at its end, non-transparency, "open" community project ... (was: No more kernel-source(code) ???)

Alexandre Oliva aoliva at redhat.com
Fri Jun 25 18:21:52 UTC 2004


On Jun 25, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:

> Please revert this, until we find a real solution, can you?

No, I can't.  I'm as much of a bystander as you.

I'm very much delighted, however, that my rawhide daily rsyncs no
longer have to download N+1 copies of compressed kernel sources, where
N is the number of arches I keep in my local rawhide replica.  1 copy
is enough, and the kernel SRPM is the right location for the kernel
sources.

If you want to build a kernel, there's a well-known procedure to turn
a source RPM into a binary RPM.

If you want to build an external module, follow the procedure that has
been documented for, what, years?, namely, using
/lib/modules/<version>/build instead of relying on /usr/src/linux

If you want to build modules from this kernel, extract the sources
using the well-known procedure and build them however you like, as if
they were an external module.

The procedures above have worked for years.  Sure, they may be
different from those you got used to, and they may very well not be as
convenient for you as forcing everyone who would like to rebuild your
packages to have the kernel-sourcecode package already installed, or
automatically brought in by dependencies.


The only actual change in procedure by not offering kernel-sourcecode
as a binary rpm is that you can no longer bring it in with a
BuildRequires.  This will require binary module packages to be more
conscious in (i) following the documented procedures to build kernel
modules, instead of ad-hoc solutions that happened to work but, since
they were not documented or recommended, were prone to changes, and
(ii) in the case of building modules that are part of the kernel,
packaging their sources instead of relying on a redundant and
hopefully obsolete packaging artifact to obtain them.

Yeah, change can be a pain.  But I really believe this change is for
better.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}





More information about the fedora-devel-list mailing list