Re: 3.2 transition
Anthony Towns schrieb:
On Tue, Dec 17, 2002 at 07:54:32PM +0900, Junichi Uekawa wrote:
I've thought having a directory for doing LD_LIBRARY_PATH might help
people keep compatibility with other dists or legacy applications,
What other dists or legacy applications? Do you have examples?
Anyone who has locally built a c++ application on their system
is going to be broken.
Yes, do you have any examples? If there are real world examples, then
that's something interesting that might be worth working on.
I want to mention another class of examples: gtkmm/sigc++ based programs.
Since I wrote a lot of complex gtkmm programs for local
(manuproc.berlios.de & unpublished friends) and public use (e.g.
midgard.berlios.de) I have lots of real world examples to give.
And as a debian administrator (~10 computers) I qualify as a person
going to be biten by the change (or benefitting from it).
- Gtkmm2 programs tend to crash when compiled with 2.95 (the
dynamic_cast bug) [If you used glade--, they always crash!]. So for any
gtkmm2 development I'm forced to rebuild the needed packages with 3.2
right now. _Please_ do not delay shipping libraries compiled with 3.2
- There might be old versions of C++ libraries around which _might_ be
sensible to still ship built with 2.95, since they do not get used in
new programs. E.g. libstdc++-1.0 and libgtkmm-1.2, the gnomemm 1.2
packages. This means cheap binary compatibility to woody. But
identifying and patching the packages which need them (and therefore
2.95) to build is not a task I'd love to do. This situation is
comparable to kde2 packages. Also this would keep the list of still 2.95
using programs longer.
- I do not mind if I have to recompile programs for this switch. Though
this is a lot of work (up to 20 different c++ applications). If I really
want to continue using old binaries, I can set libgtkmm and libsigc++ to
hold (or make a local copy of the *.so.* files).
- I'd never use unstable on critical servers (where breakage would mean
instant work under time presssure). But I'm not convinced that it's
worth the hassle to provide libfoo.so.* compiled with 2.95 for people
using testing. 3.2's benefits outweight the recompile/LD_LIBRARY_PATH
nuisance during the transition.
We may need to add in our release notes: "We broke ABI, please recompile
Well, yes. "We updated GCC which breaks the C++ ABI; if you have
complicated C++ programs, please rebuild them."
Perhaps listing the C++ libraries with this issue in an appendix might
be a good idea. [libxerxes, libsigc++ (and therefore libgtkmm), libqt]
An easy ldd will tell you about compatibility.
It might suffice to instruct users to install packages from woody,
Before we spend time, effort or imagination on this, there needs to be
some evidence that it'll actually benefit people.
does this mail help?
"3.2 now!" will benefit me most ;-) I don't care much for compatibility
libraries (and longer delay).