When dealing with a large installed base of proprietary applications (and, even legacy source-available ones), simply stating that the "proper" solution to version mismatch is to recompile the applications is misguided at best, willfully negligent at worst.
The fact remains that a huge amount of Linux applications were compiled against libstdc++5 up until very recently (e.g. I have firefox 2 stuff still dependent on it, amongst others). Actively removing support for this library, without providing some sort of reasonable transition period isn't smart. It's not as if we're talking about a few applications, or even only applications more than 5 years old. The problem is that up until very recently, there were a large number of distribution versions (e.g. RHEL 2.1, SLES 8) still in service which didn't support libstdc++6, which meant that OEMs HAD to link against libstdc++5 to achieve cross-compatibility. When depricating software, a WELL PUBLICIZED transition period is expected (and, frankly, is the professional way to handle things). Here, libstc++5 should be moved to another, non-core package (see #39 as the proper way to handle obsoleting something). We should also file bug/RFE reports to the various software producers, to make sure they're well-informed about moving to libstdc++6 for their products. Realistically, if the libstc++5 was to be transitioned away from, then by all means remove it from the ia32-libs package. But it should defintely be packaged elsewhere in the standard repositories, for installation as required. Deciding that it should just be chucked because it was "too hard" to maintain isn't an acceptable idea. Looking at the "workaround" in #17 is illustrative for two reasons: (a) this problem is still of sufficient importance to require an involved workaround and (b) the workaround is complex, which means that there is still a problem with the underlying software (in this case, the ia32-libs package). Given the rather large amount of OEM software out there still dependent on libstdc++5, and the timeframe as to migrating from that "obsolete" software, my estimate is that we still have 3-5 years before being able to completely remove libstdc++5 from being supported. I'm changing the status on these to "Confirmed" as this really is a problem that has to be solved, rather than simply bypassed. -- libstdc++5 removal breaks non-ubuntu applications https://bugs.launchpad.net/bugs/431091 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
