>> Junichi Uekawa <[EMAIL PROTECTED]> writes: > Consider a situation: > A->libA->libpng2(nover) > A->libpng2(nover)
> if libA was recompiled with libpng3(versioned), then > libA->libpng3(versioned), but A won't be. > > upgrading libA only might cause A to fail ? It depends. What is A? A package? Something else? If it's a package, for discussion purposes let's say versions 1.0.12-5 and 1.2.1-4 of libpng[23] introduce versioned symbols (adjust to match reality, I'm going from memory here). Please bear with me here, I'm second guessing you, I really don't know what's in your mind, but I think you mean this: Package: A Depends: libA, libpng2 Package: libA Depends: libpng2 Version: 3.1-4 now libA is recompiled: Package: libA Depends: libpng3 (>= 1.2.1-4) Version: 3.1-4.1 but Package A hasn't been recompiled yet, that is, there is no: Package: A Depends: libpng2 (>= 1.0.12-5), libA That means it is installable by doing: $ apt-get install A which in this state leaves you with a non-working program. Same thing for upgrading just libA. And that's precisely the reason why we are doing this in two steps: first recompile everything against the new libpng libraries, and /then/ recompile against libpng3. Now, if you are talking about something that is not a package, no, I don't have a solution for that other than well written documentation. The only solution to this is mockering with SONAMEs, but I'll oppose vocally to that. The interoperability problems that *that* would cause are not worth it. -- Marcelo
