On Fri, Aug 16, 2002 at 09:47:25PM +0200, Martin v. Loewis wrote: > Not necessarily: you can write wrapper scripts around the executable > which automatically set LD_LIBRARY_PATH, then invoke the original > binary. That has worked very well in the past. > If you mean that the manual intervention is need by package > maintainers: indeed they'd need to act. So this would be restricted to > packages for which no source code is available. > The majority of such packages links to libstdc++ only, so there may be > no need for action at all. Do we have non-free C++ packages that we have to worry about? My comments were more directed at unpackaged software that users may be running on their Debian systems. In those cases, providing a way to get their binaries working again /after/ we break them is only a little bit better than forcing them to recompile. > > My concern is that locally compiled apps built against C++ libraries > > other than libstdc++ will silently stop working on upgrade. This is > > certainly not the most important issue facing us in the transition, > > but so far it seems to me that people are regarding it as so > > *un*important that it's not worth discussing at all. > The breakage will not be silent: On startup of the application, they > will give an error message indicating the problem. I think that > problem is best solved by educating the users that such problems might > happen. It is silent in the sense that the package management system will give no indication that the new libfoo++.so.n is not compatible with the old libfoo++.so.n; only locally compiled, /packaged/ apps will be tipped off to the problem. Steve Langasek postmodern programmer
Attachment:
pgp_v0EEnH162.pgp
Description: PGP signature