Hi,
It's that time again! Fedora Core 4 no longer installs the compat-libstdc++ package by default, meaning that any users who install or run a C++ app which was built using GCC 3.3 or lower is now greeted with an incomprehensible and unhelpful error (or nothing, if they use the GUI).
C++ is used by a lot of games and other commercial apps. Virtually none use the new C++ DSO version. Many never will.
The release notes talk repeatedly about the "solid platform" that GCC 4 brings: this must be some new use of the word platform I have not yet encountered as to me the word platform implies some measure stability.
This sort of thing crops up with every Fedora release. The message now, as then, is simple: this gratuitous and unnecessary breakage of backwards compatibility must end. If it does not all the work GNOME and the rest of the Fedora desktop team is putting in will be wasted - a usable desktop that falls flat on its face the moment you leave the CD set behind is not usable in the real world at all.
Please, save the usual replies. I know some here think any packages not used within the distribution should be dropped. I know some don't care about games (even the open source ones). I don't want to hear it - Fedora is not the universe, and if it wishes to be taken seriously should not pretend to be.
thanks -mike
On Sat, Jun 25, 2005 at 12:04:19AM +0100, Mike Hearn wrote:
Hi,
It's that time again! Fedora Core 4 no longer installs the compat-libstdc++ package by default, meaning that any users who install or run a C++ app which was built using GCC 3.3 or lower is now greeted with an incomprehensible and unhelpful error (or nothing, if they use the GUI).
There is no compat-libstdc++ package in FC4, only compat-libstdc++-296 and compat-libstdc++-33. Both are included in the Legacy Software Support group (which is rather small). Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO.
Jakub
On 6/24/05, Jakub Jelinek jakub@redhat.com wrote:
Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO.
I think... the long term solution to address this issue, is to first find a way to inform users that a library is missing. Launching an app with a missing library from the gnome panel or menu doesn't give you feedback about the missking library. And beyond that hook the notification into a query of the configured repository metadata to make a suggestion as to what to install to get the missing library.
-jef
On Fri, 2005-06-24 at 19:26 -0400, Jeff Spaleta wrote:
On 6/24/05, Jakub Jelinek jakub@redhat.com wrote:
Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO.
I think... the long term solution to address this issue, is to first find a way to inform users that a library is missing. Launching an app with a missing library from the gnome panel or menu doesn't give you feedback about the missking library. And beyond that hook the notification into a query of the configured repository metadata to make a suggestion as to what to install to get the missing library.
-jef
While I agree with Jef that there needs to be some GUI feedback when dynamic linking fails, another useful long term solution would be to beat the C++ people with a cluebat until they stop breaking the ABI every release.
On Fri, 2005-06-24 at 19:19 -0400, Jakub Jelinek wrote:
Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO.
Well, it is simply because things will silently break without the user having any clue WTF is wrong. And yeah, 'forcing' it for everyone is not such a bad idea, all they lose is a little HD space. If we start arguing about a few megabytes, this is not the place to save them.
And given the virtual zero cost for most people, breaking stuff silently for some is definitely a bad idea.
On Sat, Jun 25, 2005 at 12:29:11AM -0400, Dimi Paun wrote:
On Fri, 2005-06-24 at 19:19 -0400, Jakub Jelinek wrote:
Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO.
Well, it is simply because things will silently break without the user having any clue WTF is wrong. And yeah, 'forcing' it
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
for everyone is not such a bad idea, all they lose is a little HD space. If we start arguing about a few megabytes, this is not the place to save them.
The argument that Core needs to include everything just because some not properly packaged third party software might ever need it would is certainly not going to fly. What is so special about compatibility libstdc++?
Jakub
Jakub Jelinek wrote:
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
Won't the ones making those rpms have to look into the future and require that compat-libstdc++-XX is installed, even though that package doesn't exist yet for the current FC version?
Otherwise I can't see how you can make yum do the right thing for an old app, maybe less than 6 months old even.
/cjk
On Sun, 2005-06-26 at 12:58 +0200, Carl-Johan Kjellander wrote:
Jakub Jelinek wrote:
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
Won't the ones making those rpms have to look into the future and require that compat-libstdc++-XX is installed, even though that package doesn't exist yet for the current FC version?
nope
rpm makes it a nice automatic versioned library dependency; there is no need to depend on any package name directly.
On Sun, 2005-06-26 at 12:58 +0200, Carl-Johan Kjellander wrote:
Jakub Jelinek wrote:
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
Won't the ones making those rpms have to look into the future and require that compat-libstdc++-XX is installed, even though that package doesn't exist yet for the current FC version?
No. rpmbuild will pick up the library dep, and yum will fulfill it.
On Sun, 26 Jun 2005 12:58:49 +0200, Carl-Johan Kjellander wrote:
Won't the ones making those rpms have to look into the future and require that compat-libstdc++-XX is installed, even though that package doesn't exist yet for the current FC version?
The problem is that:
a) This requires every RPM to be in a yum repository. Usually if they aren't in Extras, FreshRPMs, Dag or somesuch then they are just an RPM on a download page. Then automatic dep resolution doesn't work.
b) As the package is considered legacy, at some point it'll probably disappear entirely like NPTL is going to do (argh).
So apart from shipping a private copy of the standard library there isn't really anything you can do here, except try and become a part of the "in crowd" by getting into Fedora Extras which puts you at the whim of Red Hat legal (and obviously doesn't work at all for commercial/free-as-in-beer software like RealPlayer). I know Real have got the same problem with libstdc++.so.5 disappearing, tech support requests are starting to appear.
thanks -mike
On Sun, 2005-06-26 at 21:11 +0100, Mike Hearn wrote:
The problem is that:
a) This requires every RPM to be in a yum repository. Usually if they aren't in Extras, FreshRPMs, Dag or somesuch then they are just an RPM on a download page. Then automatic dep resolution doesn't work.
With system-install-packages apparently moving toward a yum backend (or with whatever yum GUI we end up with), it ought to be fairly straightforward to try and resolve deps from configured repositories even when installing non-repo RPMs. In the FC4 case, that would fix your issue a) above for compat-libstdc++-33, right?
Mitch
Mitch Skinner wrote:
On Sun, 2005-06-26 at 21:11 +0100, Mike Hearn wrote:
The problem is that:
a) This requires every RPM to be in a yum repository. Usually if they aren't in Extras, FreshRPMs, Dag or somesuch then they are just an RPM on a download page. Then automatic dep resolution doesn't work.
With system-install-packages apparently moving toward a yum backend (or with whatever yum GUI we end up with), it ought to be fairly straightforward to try and resolve deps from configured repositories even when installing non-repo RPMs. In the FC4 case, that would fix your issue a) above for compat-libstdc++-33, right?
This can already be addressed in FC4 using:
# yum localinstall some-package.rpm
where yum will go off and get any required dependencies for the rpm to be installed.
Pau.
On Mon, 27 Jun 2005 04:44:28 -0700, Mitch Skinner wrote:
In the FC4 case, that would fix your issue a) above for compat-libstdc++-33, right?
Not really, my issue is that I'm distributing software that doesn't use RPMs (because doing so is not really practical or sensible). Any solution that involves the user understanding yum or RPM doesn't work.
thanks -mike
On Sun, 2005-06-26 at 12:58 +0200, Carl-Johan Kjellander wrote:
Jakub Jelinek wrote:
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
Won't the ones making those rpms have to look into the future and require that compat-libstdc++-XX is installed, even though that package doesn't exist yet for the current FC version?
Otherwise I can't see how you can make yum do the right thing for an old app, maybe less than 6 months old even.
Commercial apps probably have the biggest trouble, since they usually don't use RPMs and the installer is not usually smart enough to recommend installing a certain package. A few I've run into are smart enough to check and at least stop the install saying you need libraries foo & bar installed.
Paul Berger
From: "Jakub Jelinek" jakub@redhat.com
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
That doesn't mean breaking things on purpose. Pissing off customers is not The Right Thing (TM), last time I've checked.
Waiting a few more years before yanking system libs from under people's feet would be the more prudent thing to do. And it costs so little, it's not even funny that it's not being considered.
Dimi Paun dimi@lattica.com wrote:
From: "Jakub Jelinek" jakub@redhat.com
As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself.
That doesn't mean breaking things on purpose.
Isn't, AFAICS.
Pissing off customers is not The Right Thing (TM), last time I've checked.
Right.
Waiting a few more years before yanking system libs from under people's feet would be the more prudent thing to do. And it costs so little, it's not even funny that it's not being considered.
This is /Fedora/, commited to being bleeding edge (or thereabouts). So the "have everybody retain libraries for some years for nostalgia's sake" doesn't belong here. Sure, perhaps making a group of "legacy libraries, needed for some third party software" stand out when installing might be a good idea.
On Tue, Jun 28, 2005 at 10:22:53AM -0400, Horst von Brand wrote:
This is /Fedora/, commited to being bleeding edge (or thereabouts). So the "have everybody retain libraries for some years for nostalgia's sake" doesn't belong here. Sure, perhaps making a group of "legacy libraries, needed for some third party software" stand out when installing might be a good idea.
Such group exists and the libraries we are talking about are in that group. The disagreement is whether it ought to be installed by default or not, and the choice Fedora is making is not installing that group by default, and you need to click one checkbox to change that.
As the majority of people don't need those and even for those that need it the majority will use rpm where yum localinstall etc. can handle the dependencies automatically, IMHO that's the right default choice.
Jakub
On Fri, 24 Jun 2005 19:19:32 -0400, Jakub Jelinek wrote:
There is no compat-libstdc++ package in FC4, only compat-libstdc++-296 and compat-libstdc++-33.
Yes, sorry, I was referring to the compat-libstdc++-33 package.
Both are included in the Legacy Software Support group (which is rather small). Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO.
Well, nobody knows whether they need it until they choose some random software and find that it's considered "legacy". In particular new software is often compiled against older DSO versions so the binaries work on more distributions, so this distinction is quite subtle.
I don't think installing it by default really costs anything. It's, what, 3mb? If it's not installed by default then many users who just choose the Personal/Workstation install won't get it. Then they post tech support requests to my forums asking why they get this strange error they don't understand. This is the GNOME philosophy of "Just Works" defaults again - nobody suffers if the package is installed but not used, but people do suffer is the package is not installed and used.
As to whether RPM should take care of this or not, well, there are many programs that are not in any repository. Maybe in an ideal world where every Linux user used Fedora and so every program was in some repository, then maybe ... but that isn't the current world so we can't assume people use RPM for everything.
thanks -mike
On Sat, 2005-06-25 at 00:04 +0100, Mike Hearn wrote:
[snip]
Please, save the usual replies. I know some here think any packages not used within the distribution should be dropped. I know some don't care about games (even the open source ones). I don't want to hear it - Fedora is not the universe, and if it wishes to be taken seriously should not pretend to be.
Let me get this straight. You post your usual complaint about Fedora Core making it difficult for proprietary apps and open source developers who don't want to package their apps as rpms and submit them to *some* yum repo (or set up their own), and then don't want to hear the usually response? Yup, you're absolutely right. Fedora is NOT the universe. And anyone who expects Fedora to take the universe into consideration is going to be profoundly disappointed. I, for one, prefer Fedora to move forward, getting rid of old, crufty compat-* packages giving low priority to those who don't want to adapt their apps to Fedora's fast moving pace. *You* may not take Fedora seriously. I don't need backwards compat cruft for *me* to take it seriously. Even with being considered for the 'hobbyist, enthusiast, developer.' You want something that moves slower? Buy RHEL, or grab a copy of CentOS. Otherwise, take up the mantle and initiate the Fedora Compat project to scratch your own itch. You don't want to be beholden to Red Hat legal? Then don't call it that.
On 6/26/05, Paul Iadonisi pri.rhl4@iadonisi.to wrote: [...]
I, for one, prefer Fedora to move forward, getting rid of old, crufty compat-* packages giving low priority to those who don't want to adapt their apps to Fedora's fast moving pace. *You* may not take Fedora seriously. I don't need backwards compat cruft for *me* to take it seriously. Even with being considered for the 'hobbyist, enthusiast, developer.'
Is gcc 3.3 old and crutfy? Wow. 1 year ago?. Well, this compat breaking from gcc people plus non "old and crutfy" support on distros is making C++ (and gtkmm) a non possible platform for ISV's making software for Linux. And ISV don't have resources to package their application for every Linux distro, setting up repositories, etc... They just want to put a package and allow people to download it and install it easily.
We have very few ISV making software for linux now, because we have very few desktop share, but this is changing...
Salu2
On Mon, 2005-06-27 at 00:17 +0200, Fernando Herrera wrote:
On 6/26/05, Paul Iadonisi pri.rhl4@iadonisi.to wrote: [...]
I, for one, prefer Fedora to move forward, getting rid of old, crufty compat-* packages giving low priority to those who don't want to adapt their apps to Fedora's fast moving pace. *You* may not take Fedora seriously. I don't need backwards compat cruft for *me* to take it seriously. Even with being considered for the 'hobbyist, enthusiast, developer.'
Is gcc 3.3 old and crutfy? Wow. 1 year ago?. Well, this compat breaking from gcc people plus non "old and crutfy" support on distros is making C++ (and gtkmm) a non possible platform for ISV's making software for Linux.
This wouldn't be a problem if the C++ people stopped breaking the C++ ABI every single release.
And ISV don't have resources to package their application for every Linux distro, setting up repositories, etc... They just want to put a package and allow people to download it and install it easily.
We have very few ISV making software for linux now, because we have very few desktop share, but this is changing...
On Mon, 2005-06-27 at 00:17 +0200, Fernando Herrera wrote:
[snip]
Is gcc 3.3 old and crutfy? Wow. 1 year ago?.
Bad example. Read Dan William's post to this list titled "Re: Why no compat-gcc-3.4.3-22.fc4.i386.rpm ?" and dated "Thu, 23 Jun 2005 23:20:44 -0400 (EDT)". Gcc32 (compat-gcc-32-3.2.3-47) and GCC4 (gcc-4.0.0-8) are included which cover enough of the bases.
Well, this compat breaking from gcc people plus non "old and crutfy" support on distros is making C++ (and gtkmm) a non possible platform for ISV's making software for Linux.
You're really blowing this out of proportion. They can do what VMware does, for example, by including a copy of gtk2 2.4.0. Even including it as an optional component (for older or newer OS releases) would work and not increase the size of their package for the OS releases they target.
And ISV don't have resources to package their application for every Linux distro, setting up repositories, etc... They just want to put a package and allow people to download it and install it easily.
Then put it in a tarball, provide a short doc with known dependencies, and allow third parties to submit patches and/or spec files and/or whatever-it-is-debian-uses-to-build-packages. Sure, I'd rather see VMware always released in an rpm package for the latest and greatest Fedora Core release. But if they complain, I'd say just externalize *more* of their costs and let others either package it or provide an easy way to package it. (And as a side note, don't have a license that prohibits this type of activity.)
We have very few ISV making software for linux now, because we have very few desktop share, but this is changing...
And it will continue to change. Despite the ISVs. Make it difficult for the ISVs for the sake of making it difficult for them? No, that would be silly. But for the sake of forward movement and doing things better, I don't think we should be bending over backwards to provide backward compatibility for them. If C++ developers in particular want to complain, they need to direct at the GCC C++ team for breaking binary compatibility. Fedora Core 4 has the compromise of 3.2.3 and 4.0.0.
On Sun, 26 Jun 2005 17:56:59 -0400, Paul Iadonisi wrote:
Yup, you're absolutely right. Fedora is NOT the universe. And anyone who expects Fedora to take the universe into consideration is going to be profoundly disappointed.
I don't think you work for Red Hat, but regardless it says on the Fedora about page:
"The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system"
which by definition means it needs to take the universe into consideration. If it doesn't then it's not, by any widely accepted definition of the word, an operating system.
One of the goals is:
"Create a complete general-purpose operating system with capabilities equivalent to competing operating systems"
Windows and MacOS have good backwards compatibility, and that's a capability. So we need to match it.
Another goal is:
"Provide a robust development platform for building software, particularly open source software."
But a platform that constantly shifts, changes, and in which parts disappear at a moments notice is not robust.
Yet another goal is:
"Emphasize usability and a "just works" philosophy in selecting default configuration and designing features."
But dropping GCC 3.3 C++ support from the default configuration makes it less Just Works and more like the Linux we know from the old days: requires fiddling and expertise to make it work.
I think you see my point.
thanks -mike
On Sun, 2005-06-26 at 23:30 +0100, Mike Hearn wrote:
[snip]
I don't think you work for Red Hat, but regardless it says on the Fedora about page:
Well, I'm not sure if it has anything to do with the rest of your message, but I guess I'm now outed. ;-) As of about a month ago, I do work for Red Hat. But certainly not in development and likely don't have any more direct influence than anyone else on this list as a result of my employment.
"The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system"
which by definition means it needs to take the universe into consideration.
That's quite a leap. By whose definition?
If it doesn't then it's not, by any widely accepted definition of the word, an operating system.
So VxWorks is not an operating system? SymbianOS (sp?)? PalmOS? QNX? None of those are what I would call general purpose, but they sure are operating systems.
One of the goals is:
"Create a complete general-purpose operating system with capabilities equivalent to competing operating systems"
Windows and MacOS have good backwards compatibility, and that's a capability.
Depends. Personally, I wouldn't call backwards compatibility a 'capability', per se. It's preserving old capability, so in that sense, yes.
So we need to match it.
No, we don't. But if someone wants, they are free to set up a Fedora Compat repo, complete with kernels without nptl (if that's possible) and gcc/glibc packages that provide older compat-* pieces to allow older apps to run.
Another goal is:
"Provide a robust development platform for building software, particularly open source software."
But a platform that constantly shifts, changes, and in which parts disappear at a moments notice is not robust.
For the particular issue you bring up in the beginning of this thread, all that is required is to package your product according to Fedora standards and provide a yum repo.
Yet another goal is:
"Emphasize usability and a "just works" philosophy in selecting default configuration and designing features."
But dropping GCC 3.3 C++ support from the default configuration makes it less Just Works and more like the Linux we know from the old days: requires fiddling and expertise to make it work.
A mime type entry to bring up a little usermode enabled applet when a '.repo' file into /etc/yum.repos.d/ would be a nice addition to the distro. For those who want their apps to Just Work with Fedora Core, provide an rpm, a yum repo, and an app.repo file. Or, take submissions from your users who care and are capable to provide it. I interpret Just Works somewhat different than you. And that is that everything *within the distro (and extras)* should Just Work.
I think you see my point.
Oh, I do. I just don't agree. And on top of that, I believe you picked and chose what you like out of that list of objectives. I see nothing in there specifically about backward compatibility, and there's a glaring absence of mention of anything to do with proprietary software in particular. That wasn't an oversight. And there are a number of statements like "exclusively from open source software" and "leading edge of open source technology, by adopting and helping develop new features and version upgrades" and "encouragement and support exists for third party packaging" that, to me, imply that those who crafted these objectives were deliberate in not mentioning backward compatibility or proprietary software or software not properly packaged.
On Sun, 2005-06-26 at 19:29 -0400, Paul Iadonisi wrote:
[snip]
A mime type entry to bring up a little usermode enabled applet when a '.repo' file into /etc/yum.repos.d/ would be a nice addition to the distro.
argh. That should read:
"A mime type entry to bring up a little usermode enabled applet when a '.repo' file is clicked on that will drop it into /etc/yum.repos.d/ would be a nice addition to the distro."
On Sun, 2005-06-26 at 21:46 -0400, Paul Iadonisi wrote:
On Sun, 2005-06-26 at 19:29 -0400, Paul Iadonisi wrote:
[snip]
A mime type entry to bring up a little usermode enabled applet when a '.repo' file into /etc/yum.repos.d/ would be a nice addition to the distro.
argh. That should read:
"A mime type entry to bring up a little usermode enabled applet when a '.repo' file is clicked on that will drop it into /etc/yum.repos.d/ would be a nice addition to the distro."
Stuff that /etc/yum.repos.d/blah.repo into a RPM and you're done. FreshRPMs and (iirc) Livna do this right now.
On 6/26/05, Mike Hearn mike@plan99.net wrote:
Windows and MacOS have good backwards compatibility, and that's a capability. So we need to match it.
Apple garuntees very limited backwards compatibility for c++ dso STARTING with the introduction of gcc 4.0 http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntim...
quoting http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntim...
"Apple guarantees ABI stability only for core language features. It does not guarantee stability for library classes, including std::string, std::map<T>, and std::ostream among others."
quoting http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntim...
"If your application must support versions of Mac OS X prior to 10.3.9, you must continue to link statically to libstdc++.a. You should also not use the GCC 4.0 compiler to create C++ programs for systems prior to 10.3.9"
How about we not make over-reaching claims about what other operating systems do about backwards compatibility. If ALL application writers in the universe were linking statically to libsdc++ like Apple demanded before the release 10.3.9 would there be much to talk about in this thread?
Do not confuse the objective list for Fedora as a set of garuntees for any Fedora Core release. Those objectives are long term goals that the project is working towards. If the upstream project developers stability of the exposed interfaces... 3rd party vendors should absolutely be aware of that before they decide to link dynamically to the library. Holding the downstream distributor responsible for the lack of stability is a bit.. short-sighted.
-jef
On 6/26/05, Jeff Spaleta jspaleta@gmail.com wrote:
If the upstream project developers stability of the exposed interfaces...
that should read: If the upstream project developers do not promise stability of the exposed interfaces
-jef
On Sun, 26 Jun 2005 19:47:53 -0400, Jeff Spaleta wrote:
about we not make over-reaching claims about what other operating systems do about backwards compatibility. If ALL application writers in the universe were linking statically to libsdc++ like Apple demanded before the release 10.3.9 would there be much to talk about in this thread?
Nope, probably not, and bundling private libstdc++.so versions is likely to be the route we'll take. That's a shame because it's 3mb of overhead most apps don't want, but if there's no other way then so be it.
Holding the downstream distributor responsible for the lack of stability is a bit.. short-sighted.
Well, the whole point of soname versioning and renaming the library when it changes its exported interface is so they can be parallel installed. I don't think it's too much to ask that it's installed by default which is definitely a downstream decision.
thanks -mike
Hi
Well, the whole point of soname versioning and renaming the library when it changes its exported interface is so they can be parallel installed. I don't think it's too much to ask that it's installed by default which is definitely a downstream decision.
thanks -mike
It doesnt have to be part of the base installation. Would it be possible to have the compatibility libraries within the legacy group selected by default. Users who do not require it can explicitly deselect it during the installation or do a yum groupremove easily. Others get more compatibility and external packages working better until a more automated message using dbus or something is designed to cover such cases better
regards Rahul
Rahul Sundaram wrote:
It doesnt have to be part of the base installation. Would it be possible to have the compatibility libraries within the legacy group selected by default. Users who do not require it can explicitly deselect it during the installation or do a yum groupremove easily. Others get more compatibility and external packages working better until a more automated message using dbus or something is designed to cover such cases better
IIRC, the compatibility libraries are down in the "Development" section. Moving them to a more prominent (and accurate) location might be some- thing that everyone can agree on?
Hope springs eternal.
On Mon, 2005-06-27 at 12:15 +0100, Mike Hearn wrote:
[snip]
I don't think it's too much to ask that it's installed by default which is definitely a downstream decision.
It is when you consider that it is making up for developers of what I would call 'problem' apps being unwilling to cooperate and provide that rather simple procedure of yumifying their ftp site with their rpms. As far as those who don't package their apps as rpms or take contributions from their community of users to create a package from their tarball...well, there we have a bigger problem. The only thing Fedora should do in those cases is encourage and instruct them in building rpms.
On 6/27/05, Mike Hearn mike@plan99.net wrote:
Nope, probably not, and bundling private libstdc++.so versions is likely to be the route we'll take. That's a shame because it's 3mb of overhead most apps don't want, but if there's no other way then so be it.
I find that argument about statically linking... satisifyingly ironic... considering part of you argument for installing it by default is that users don't really caring about a a few 3 mb compatibility packages on the system here or there. I think you should probably avoid arguments reference when 'most' 3rd party vendors or 'most' users want. I think 'most' of the people watching the conversation probably agree that neither of us is in a good position to know the desires of 'most' of either population.
Well, the whole point of soname versioning and renaming the library when it changes its exported interface is so they can be parallel installed. I don't think it's too much to ask that it's installed by default which is definitely a downstream decision.
We disagree. Some libraries are unstable, and I think software vendors should be responsible for doing their own due diligence about what to expect in terms of promised stability of the interface BEFORE they decide to link dynamically to a library. Since this whole 'platform' idea seems to be your cup of tea, perhaps you can make a summary list of which libraries have a commitment by the upstream project for ABI and API stability as a guide to 3rd party software vendors to use to make decisions about what to dynamically link against.
-jef
On Mon, 27 Jun 2005 09:42:37 -0400, Jeff Spaleta wrote:
find that argument about statically linking... satisifyingly ironic... considering part of you argument for installing it by default is that users don't really caring about a a few 3 mb compatibility packages on the system here or there.
It's not about disk space, it's memory usage and download sizes.
thanks -mike
On Tue, 2005-06-28 at 16:04 +0100, Mike Hearn wrote:
On Mon, 27 Jun 2005 09:42:37 -0400, Jeff Spaleta wrote:
find that argument about statically linking... satisifyingly ironic... considering part of you argument for installing it by default is that users don't really caring about a a few 3 mb compatibility packages on the system here or there.
It's not about disk space, it's memory usage and download sizes.
And security. Remember all the applications that had to be updated because they statically linked zlib instead of benefiting from a updating a single dynamically linked library? There a good reasons for the mess of interdependencies in Linux.
That said, the Windows world has been shipping OS libraries with applications for some time. Sure it's ugly, but you make your choices and you live with their consequences. Anyone using proprietary software on Linux should expect some bumps. As for F/OSS, try tapping the user community to find someone willing to do the integration. If there's enough demand, someone will eventually step forward.
From: "Mike Hearn" mike@plan99.net
Nope, probably not, and bundling private libstdc++.so versions is likely to be the route we'll take. That's a shame because it's 3mb of overhead most apps don't want, but if there's no other way then so be it.
Not to mention that this means the system will not be able to share the lib if more than one C++ app runs at the same time.
So we're trading about 3MB of disk space (approx. $0.001) for 3MB * N of RAM (where N is the number of apps, which is > $0.12 even for N=1).
Smart.
And did I mention the time, effort, and _frustration_ of users to get the system running again? What if they didn't install via RPM? Screw them, they deserve what they get, no? (in which case they have a snowball's chance in hell of fixing the breakage without going through hell and back).
On Mon, 2005-06-27 at 09:44 -0400, Dimi Paun wrote:
And did I mention the time, effort, and _frustration_ of users to get the system running again? What if they didn't install via RPM? Screw them, they deserve what they get, no? (in which case they have a snowball's chance in hell of fixing the breakage without going through hell and back).
I'd choose to place the onus on the developers. If they want their users to have a good experience, let them do the leg work. Right now, I'd argue that Windows is the gold standard of backwards compatibility. Partly because Microsoft tries hard to keep things compatible, but mostly because behind the scenes there are individual application developers bleeding, sweating, crying, and cursing. If you're going to use proprietary software, don't expect anything better better support than you had in the propriety world. If you use F/OSS and the community isn't large enough to support itself yet, start contributing or pay someone else to do it. There Ain't No Such Thing As a Free Lunch.
I'm personally in favor of installing compat libs by default as long as someone it taking responsibility for handling security maintenance. I would also love to see good technical suggestions. A few interesting ideas have been suggested. But complaining isn't helpful. Arguing that Fedora or any F/OSS developer is morally obliged to bend over backwards to please users for free is repugnant. (BTW, if you think my attack and characterization is unfair, so was yours.)
From: "Stuart Jansen" sjansen@gurulabs.com
ideas have been suggested. But complaining isn't helpful. Arguing that Fedora or any F/OSS developer is morally obliged to bend over backwards to please users for free is repugnant. (BTW, if you think my attack and characterization is unfair, so was yours.)
Yes, it is an unfair attack. I didn't attack anybody, I just argued against the choice of not including relevant compatibility libraries.
This doesn't amount to arguing for any bending acrobatics -- just that we could make life easier for everybody if we are more careful with some of these backwards compatibility issues.
And complaining (within limits) is helpful -- how else will the Fedora project get feedback from the comunity? Isn't this the purpose of the project?
I think it's harmful to kill such feedback with "shut up, it's free" sort of attitude.
On Tue, 28 Jun 2005 23:04:58 +0530, Rahul Sundaram wrote:
Sure. Just file a enhancement against anaconda that the legacy group should be in the default list.
Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162069
On Sat, 2005-06-25 at 00:04 +0100, Mike Hearn wrote:
It's that time again! Fedora Core 4 no longer installs the compat-libstdc++ package by default, meaning that any users who install or run a C++ app which was built using GCC 3.3 or lower is now greeted with an incomprehensible and unhelpful error (or nothing, if they use the GUI).
C++ is used by a lot of games and other commercial apps.
As an ISV, our approach was to document this issue in our Knowledge Base and product documentation, to show relevant error messages at install time and to explain this behavior to our users. So far, nobody cried and all BitDefender users were able to install the proper compat-libstdc package, with or without our help.
From an ISV point of view, this is a minor issue.
On Mon, 27 Jun 2005 07:01:26 +0300, Mircea MITU wrote:
As an ISV, our approach was to document this issue in our Knowledge Base and product documentation, to show relevant error messages at install time and to explain this behavior to our users. So far, nobody cried and all BitDefender users were able to install the proper compat-libstdc package, with or without our help.
BitDefenders userbase is probably more towards the technical side of the population. Judging from your download page, which provides gcc29x and gcc3x packages with no explanation they have to be if only to figure out which of the 6 downloads they need to get. That's a far cry from your average non-technical gamer/web surfer/IM user.
thanks -mike