No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)

Jeff Spaleta jspaleta at gmail.com
Thu Jun 24 20:13:53 UTC 2004


On Thu, 24 Jun 2004 21:26:40 +0200, Ronny Buchmann
<ronny-vlug at vlugnet.org> wrote:
> But the removal of DVB modules and the name change to kernel-sourcecode are.

Let's try to keep this specific thread on topic please. Changes that
have come before with regard to released-update kernel packages will
only serve to muddy the specific issues associated with dropping
kernel-source(code) completely as a binary package moving forward.
Please lets not drag other questions into the discussion.

As a quick summary for those keeping score there are appear to be two
directly relevant issues that are going to affect module builders like
3rd party public repositories and private intranet repository
builders. Common end-user(and I dare say power-user) usage scenarios
shouldn't be affected assuming of course that post-install module
building scripts are doing the right thing and looking in
/lib/modules/`uname -r`/build/ :

1) how to deal with building modules for multiple versions of the
kernel just using the binary kernel packages without resorting to some
pedantic games to trick rpm into letting you install multiple versions
of a kernel without overwriting files for the running kernel. Ex:
building modules for i586 while running i686 kernel of the same
release.
I personally would say encoding the i586 or i686 in the release string
as a pedantic game.  If the general theme here is to make kernel
packages conform to how other packages are handled inside Core,
encoding the arch into the version seems to go against that goal. Or
do we want to do similar games with openssl and glib. A clever way to
produce a kernel-devel package like other packages get would seem to
conform best to the goal of treating kernel like every other package
in the distro.

2)Some issues with the efficiency of how hardlink is used when
installing the kernel rpms now.  This issue seems fundamentally an
optimization issue really, and not something that will break how 3rd
party and intranet repo maintainers build kernel modules. Annoy them
surely, but i think 1) is the issue that is going to have to be solved
AND documented with huge blinking neon signs, skywriters and possibly
a document projected onto the surface of the moon for all to read.

-jef"filing a bug to introduce an openssl-source(code) noarch package"spaleta





More information about the fedora-devel-list mailing list