On Wed, 2004-12-08 at 01:02 +0000, Michael A. Peters wrote: This whole compat-foo thing Red Hat/Fedora does is so incredibly goofy. It's a great example of the poor (non-existent, perhaps) packaging standards employed in those distros. Let's look at an example. Use has libfoo installed in FCX. FCY comes along with a new major version of libfoo, and a compat-libfoo. Several more revisions of FC late, libfoo is one or two more versions along, and compat-libfoo is either no longer in the distro, or doesn't have the version of foo from FCX. The user upgrades, perhaps does a fresh reinstall - either way, it doesn't matter, because the user will find that apps installed in FCX (quite possibly third party apps) no longer work. And what about the maintenance cost of the compat packages? Keeping a compat-foo package that has several major revisions in it cannot be something the maintainers enjoy doing. If the packages had just used a more intelligent naming scheme, this problem wouldn't exist, ever. Name the packages libfoo1, libfoo2, etc. Get rid of the compat-foo stuff. If you upgrade, libfoo1 stays around, libfoo2 is installed, no problems. Ten years down the road (assuming the glibc/gcc gods don't decide to screw users over again and break tons of ABI) you can still install your apps that relies on libfoo1. You may not have that package, but you can grab it online and install it, and it just works. No worries that you need an old version of compat-foo that need manual rpm -i invocation to install alongside the current compat- foo, no worries about having a 100MB compat-foo, etc. It gets better. Most of the Fedora Core 1 Extras installed on FC2, and many install on FC3. Most of the FC2 Extra install on FC3. Most of the conflicts I do run into are *not* problems with the underlying software but just poor packaging. Switching to a libfoo<version> scheme, and you could even get rid of the multi-distro Extra. Why have your servers store 3 copies of Extras when you can just have one? That also has better implications for third party packages, which quite a few users use. Even with the bazillion CDs distro ship these days (it really does seem like the Linux distribution version of a penis comparison sometimes, doesn't it?) users often need or want third party packages. Even for a lot of software Fedora ships I still use third party versions because it's goofy to have to upgrade an entire OS (and wait for said upgrade to be released, even if it is no more than 6 months) to get an updated package with bugs fixed. Fedora released are packaged like appliances. They're only intended to work with themself, and external packages only if they customize themself to the specific Fedora release. It doesn't have to be that way. The distribution can be a *platform*. Commercial *and* Open Source ISVs, and the users themselves, benefit from having a platform. It's not a big task. Just fixing the small, simple things like the curl package is really all that's needed in most cases. The fact that, as I said, Fedora Core 1 Extras *mostly* install fine on FC3 proves that.

On Wed, 08 Dec 2004 05:11:03 +0000, Michael A. Peters wrote: And 3 or 4 corresponding compiler toolkit chains, too, because you need to maintain ABI compatibility with the ten years old platforms and not just provide old libraries. In the days of package dependency resolvers, who decide for you from where to take a needed library, the package name doesn't matter much. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3 loadavg: 0.00 0.05 0.09

On Wed, 08 Dec 2004 00:24:09 -0500, Sean wrote: That's only true of ABI changes. API and semantic changes the compiler cannot magically fix. Old libraries are still necessary.

On Wed, 08 Dec 2004 06:46:35 -0500, Sean wrote: Yep, but this is quite common even for popular apps eg, XMMS still uses GTK1 and I think GNUcash still uses GNOME 1.4 - old libraries stick around for ages.