incompatible shared libraries (was Re: Guile 1.3 == SO 4)
In article <[🔎] 8790het65h.fsf@nocrew.org>, James Troup <james@nocrew.org> writes:
> I would really love to see this _sick_ habit of FUBARing library
> packages, which some maintainers seem to think is acceptable
> practice, end. If a library changes in an incompatible way (soname
> change or recompile with another library or whatever), the package
> name has to change. It's as simple as that. Anything less makes us
> look incredibly shoddy. I *don't* expect to upgrade a package with
> the debian package management system and have it break several other
> unrelated, and possibly critical applications on the system with
> *no* warning.
Definately. It makes it worse that upstream maintainers often see fit
to willy-nilly make incompatible versions of shared libraries.
I guess that's really an argument to keep experimental, pre-beta,
shared-lib providing packages out of the distribution entirely (maybe
use 'experimental'). Think of how hard Jim Pick's packaging chores
would be if he had to continue to retain a source/binary verision of
all the gnome shlib providing packages, one set for every time the
shared lib changed incompatibly.
But I agree with James that either we cannot continue the current
loose practices that many people seem to have towards shared-library
supplying packages.
Maybe we need a bit of policy or more stuff in the packaging manual
for how to maintain (long term) shared libraries, esp. across
incompatible upgrades? I'd sure love to read a good, informed,
technical treatment of this matter (as some who ships a few shared
libs)...
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: