Re: OCD programmers and backwards compatibility :-).

Tom Horsley wrote:

In fact, while we're at it - never have another "release", just keep
upgrading rpms forever with individual packages being released,
but nothing called a whole distribution having a release. Individual
rpms just get marked obsolete and replaced with new ones in the
ever updated lists.

Now *that* would be a Knight in shining armor! Fedora 7 is a mere
feeble imitation in comparison :-).

There's a great counter-example actually coming up in Fedora 7. The
kernel will switch to calling (nearly? [1]) all hard disks, PATA and
SATA alike, /dev/sdx (or whatever) as part of the switch to libsata.
This should be a lot more powerful, reliable, and maintainable.

Sounds like a better example of why linux should be more interested
in backwards compatibility than it seems to be now. Why change the /dev
names just because the underlying mechanism changes?

The most recent horrible example of this is Xorg 7 versus 6.9. The content
of the initial 7 release was absolutely identical to the content of the
final 6.9 release, but with the names of everything changed so as to
utterly devastate all 3rd party rpms that expect things to be installed
in certain places. What reason was there for this change? As near as
I can tell the only reason was a bunch of OCD programmers who broke
into a sweat every time they saw a directory named /usr/X11R6 instead
of /usr/share/X11 :-). The software worked just as well with either
directory name. If the fate of the world isn't at stake, there is no
reason to make changes like this. The cost to the rest of the world
is still being calculated as developers who could be doing something
useful spend their time "fixing" their packaging instead, and users find
all the tools they used to install don't work till they poke around on
the web for hours and find the descriptions of how to add symlinks to
their system to fix the broken installation under Xorg 7.

Sure, its a fun game, but not everyone likes playing it :-).

The same sort of attitude prevails in the kernel driver source code
as well. I've had to patch and rebuild the truecrypt driver several
times on new kernel releases, and not once has the change been anything
substantive about the driver model. Once again, it is all ticky-tak
junk like changing the name of a macro or routine because some moron
who had the power didn't like the old name and didn't care how much
work changing it foists off onto the rest of the world.

If a new kind of linux release mechanism could raise the level of
outrage over totally gratuitous non-backward compatible changes to
the point where the size of the outcry could actually make the fools
stop checking in non-backward compatible changes without fantastically
good reasons, then we NEED this new linux release mechanism :-).


I can think of three reasons this happens:
1- Group-think decisions, usually by "release teams" that have
little or no knowledge why stuff is as it was before deciding
it needs to be different "this time around" in order to make
the foobar package play nice with the rest of the release.
Of course, the new foobar package breaks compatibility with
the the last release because the developer didn't understand
how stuff works, but because the developer has the strongest
personality in the room at the time, he's managed to con the
release team into doing things his way.

2- Job security.
and
3- Because we can. Na-na-nah-boo-boo!

Cynically,

-S

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • Re: Executables of two versions in one package
    ... I wanted to know the reason for two versions in same package. ... > Could anyone clarify this? ... Which rpms do they both belong to? ...
    (Fedora)
  • Re: Executables of two versions in one package
    ... To For users of Fedora Core releases ... I wanted to know the reason for two versions in same package. ... > Which rpms do they both belong to? ...
    (Fedora)
  • Re: Executables of two versions in one package
    ... On Mon, 2005-11-07 at 10:20 +0000, Vijay Gill wrote: ... I wanted to know the reason for two versions in same package. ... > Which rpms do they both belong to? ... I have the same 2 executables, Both came from the same package. ...
    (Fedora)
  • [Full-disclosure] [FLSA-2006:152873] Updated xine package fixes security issues
    ... An updated xine package that fixes security bugs is now available. ... where is a list of the RPMs you wish to upgrade. ... have yum or apt-get configured for obtaining Fedora Legacy content. ...
    (Full-Disclosure)
  • Re: packages revisited
    ... you want to add to the general CL reader. ... I see no reason for not doing that. ... it in every package we are "in". ... If there is no such symbol, it is interned to:a-package ...
    (comp.lang.lisp)