On Tue, 15 Jun 2004 11:03:37 -0600, Dax Kelson <dax@xxxxxxxxxxxx> 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
