On Tue, 2004-06-15 at 14:32 -0400, Jeff Spaleta wrote: > 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. Sure. No argument there, however, consistency and simplicity are beneficial to everybody no matter how smart the person is. The law of least surprise. Linux, and UNIX before it, has been long subject of too many arbitrary, needless changes (behavioral and otherwise). Trivial incompatibilities suck; they are productivity and efficiency killers. > > 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. We are drifting a bit here, but I'll follow. There is no promise, but there is also sane, rational decisions that can be made to make everyones life easier and not harder. It's to everyones benefit if this thing called "Linux" is consistent whenever possible regardless of whatever distribution you happen to be using. IMO, package names *should* be part of the LSB. When adding/creating a new package for $DISTRO its wise move to do a quick survey of @OTHERDISTROS to see if they have the package and what package name they use. Unless there is some compelling reason not to, it's better to adopt the existing convention rather than fork another trivial incompatibility. This also helps reduce BuildReqs and Requires changes when porting a spec file from one distro to another. > 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. We are in agreement here, and BTW nobody (AFAIK) has argued that the noarch change was bad, just the rename. -- Dax Kelson Guru Labs
