future kernel module rpm situation (was: kernel-source vs. kernel-sourcecode (please revert))

[Jeff Spaleta]

On Tue, 15 Jun 2004 11:03:37 -0600, Dax Kelson <dax at gurulabs.com> wrote:
> My personal interest in this is as a courseware author and the "kernel
> building chapter".

Yes, well let me just say I believe in a school of educational thought
that rank orders
possible tasks in terms of level of expected active thought required
to accomplish them based on the severity of how screwed up things can
get from simple non-malicious mistakes. Its a generally useful risk
management approach, as a applicable to kernel compiles as it is to
nuclear reactor designs. You may disagree, and I'm sure you do, but I
place a custom kernel compile somewhat high up in this ranking. If
renaming the kernel-source rpm causes a significant barrier for
someone to recompiling their kernel, I think perhaps they aren't ready
to attempt it, and aren't informed enough to deal with a wide array of
potential problems associated with simple non-malicous mistakes during
a kernel compile just from configuration choices. I don't think its
wise nor do i think its in the larger public interest to create recipe
instructions for kernel recompilation aimed at people who aren't ready
to attempt the task...who aren't ready to stop and think, and to
ponder and to recover from simple errors. Like I said, you probably
disagree and thus see this change as a problem where as I see this
change as a blessed reprieve from dealing with people who rely on
cookie-cutter instructions to build kernels and expect others to
diagnose their custom kernels when their custom kernels don't do what
they want and they don't understand which config options do what. But
I'm not bitter....not bitter at all.

> As an aside, SUSE 9.1 drops the "k_" kernel RPM naming convention and
> has adopted the RH naming convention. Hooray for removing trivial
> incompatibilities!! Oh wait, here comes kernel-sourcecode. :(

You make it sound like they made the change to make your life easier
as a document writer. Perhaps they had...development reasons to drop
the k_, perhaps they just happened to align with your interests, as a
happy coincidence. There is an illusion
of consistency here. An illusion that things like package names are
standardized and agreed on across distributions. Its an illusion.
There is no promise here that package names will not change. There is
no promise nor implied promise that package naming will be the same,
don't mortage the farm on that promise.

If you pressed me to find a problem with the current situation, you
might get me to say that the decision to change the name to workaround
the bugs in yum and up2date was short-sighted, and perhaps set a bad
precendent in using workarounds instead of concentrating on finding
the real fixes when problems come up. The benefits of changing the
noarch can't really be argued against. But the benefits of changing a
package name in mid-release as a workaround for a bug, I'm not
particular sure about.

I'm not sure which is the worst situation, having yum and update fail
to see the noarch package with the same name, or to change the name of
the package and invoke an obsolete for yum and up2date to upgrade from
kernel-source to kernel-sourcecode.
As a matter of policy and precedent, requiring a package name change
to downgrade a package's arch to noarch, seems wrong. For the same
logic that Arjan wants Axel to understand that the 'right' way to deal
with kernel modules is not the 'common' way that is in use, I don't
want package renaming to work around the noarch problem in yum and
up2date to become the 'common' solution, instead i want the 'right'
solution even if that means for the moment the 'right' solution is
using rpm -e and rpm -U by hand and forsaking yum and up2date in this
corner case, a corner case Arjan admits should only be applicable to
people who are building their own kernels. Is it worth setting a
precedent to rename packages to keep functionality in yum and up2date
in this corner case?

-jef"off to talk to a publisher about his book: 12 Easy Steps to
Building Your Own Fusion Reactor"spaleta