On Wed, 2004-12-08 at 01:02 +0000, Michael A. Peters wrote: > email message attachment > On Wed, 2004-12-08 at 01:02 +0000, Michael A. Peters wrote: > > Cross posted (from fedora users to fedora-devel ... maybe we need a > > fedora-philosophy list ? ;) > > > > On 12/07/2004 12:34:23 PM, Aleksandar Milivojevic wrote: > > > Paul Howarth wrote: > > >> http://www.city-fan.org/ftp/contrib/sysutils/Mirroring/compat-libcurl-7.11.2-2.i386.rpm > > > > > > I'd kind of expect this RPM to be part of FC3 distro, but it wasn't. > > > > I agree. > > I've had to package a couple compat libraries myself (libgal2 and > > libgtkhtml3) as software I needed refused to compile against the fc3 > > (gnome 2.8) versions, but did fine against the fc2 (gnome 2.6) > > versions. > > > > I'm not sure they should be installed by default on a fc3 system - > > compat-libstdc++ does because fc3 ships with software that wants it (I > > think OO.o) - but what would be *nice* is if a fedora-compat repository > > were somewhat maintained that included binary compat shared libraries > > for cases such as these, where a third party package wants an older > > version of a shared library. 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.
