Re: library versioning: making upstream policy, need debian evaluation.
> In this case (or with something similar like an incompatible change to
> GObject*'s), how *could* you fix it so that you don't end up with a
> period where some apps are just broken for a while during the
> switchover? In the general case I'm guessing you can't, but I'm
> wondering if with a hypothetical smarter linker (or equiv) and the
> ability to keep around older copies of libs (that only vary from the
> new ones in their sub-linkages), you might be able to do a bit better.
One thing is that you cannot have Debian unstable to be unbroken
unless you do coordinated upload.
What you are describing is a situation that is very much like
perl whatever->5.5->5.6->5.7 upgrade that every perl module had to be
re-linked with the new libperl, and python 1.5->2.0->2.2 upgrade
that every python module had to be recompiled for every
standard python version.
So we have precedents in our system.
> Say you had an app foo which linked against libbar.so.1 and
> libbaz.so.1, and both of these linked against libcommon.
Take this scenario:
If you had libcommon1 package, which was used by libbar19 and libbaz2000,
when libcommon API breaks, libcommon2 is introduced, and for them
libbar20 and libbaz2001 will accompany (which build-depends on
libcommon2-dev and depends on libcommon2).
Debian unstable may have both of them or only one of them,
but user systems can have all of those packages co-installed;
so unless user is trying to re-install libcommon1 related
packages from sid after transition, users will not experience
problems, and transition will happen nondestructively.
(but yes, we do need vigorous policy for NMUing in transition,
or a very active base of developers willing to coordinate and
upload. It often helps to post notice of such ABI change
in advance of uploading to Debian unstable, like perl upgrade,
or make both versions co-installable like python upgrade.)
regards,
junichi
Reply to: