Re: Accepted sdl-image1.2 1.2.2-1 (i386 source)
>> Junichi Uekawa <dancer@netfort.gr.jp> writes:
> A user is using Debian 3.0 [...]
> I don't like long mails: they are hard to read, and I don't like
> reading them
So. Let me make this short. Read the attachment. If you find
something unsatisfactory in there, please do comment verbosely.
> If Debian wants to do a Debian local hack to one of its core
> libraries
Actually the idea is that the libpng maintainer will run this thru
upstream so other distributions can profit from the effort, too.
> which makes it binary-incompatible, then we might as well start
> changing SONAMEs of random libraries ignoring upstream
uhm... lol?
--
Marcelo | "Did you check the list?" YES. TWICE. ARE YOU SURE
mmagallo@debian.org | THAT'S ENOUGH?
| -- He's gonna find out...
| (Terry Pratchett, Hogfather)
libpng2 to libpng3 transition
=============================
In order to make sure everyone is talking about the same thing, I'll
call the library package corresponding to libpng 1.2.1 "libpng3" and its
development package "libpng3-dev". Likewise, the library corresponding
to libpng 1.0.12 will be called "libpng2" and the development package
"libpng2-dev".
Q: What's the goal?
A: Move all of Debian packages to libpng3
Q: Why?
A: First and foremost, because some development libraries depend on
libpng2-dev and others depend on libpng3-dev; since these two packages
can *not* be installed at the same time, this means you have to install
and deinstall not only libpng2-dev and libpng3-dev but also a bunch of
other -dev packages which depend on those.
Q: Why not stick to libpng2?
A: Because upstream has declared that a dead development branch, which
means bugfixes will find it way into libpng3 and libpng3 only.
Q: What's required in order to recompile a package using libpng3-dev?
A: For the large majority of packages, probably nothing. The APIs are
almost identical and the differences are only interesting if you rewrite
your package to take advantage of them. There's a catch, though. Since
the APIs are almost identical, you can't map both versions of the
library into a program's address space at the same time. In
Debian-speak, that situation happens when you have something like this:
Package: foo
Depends: libbar, libbaz
Package: libbar
Depends: libpng2
Package: libbaz
Depends: libpng3
The way the dynamic linker picks symbols from libpng2 and libpng3 when
you try to run "foo" is deterministic *but* depends on the way "foo" was
compiled. In the best case, you'll get a warning and the program won't
be able to use PNG files and in the worst case it will crash.
The rest of this document outlines an strategy to achieve an smooth
transition. I will try to point the advantages, disadvantages and more
important, the assumptions about the packages along the way. For those
of you who are too lazy to read thru this, jump to the end of the
document, you'll find a nice cliff there.
Transition strategy
-------------------
0. Recompile libpng2 and libpng3 with versioned symbols.
1. Recompile all the library packages that link against libpng2 or
libpng3. For each recompiled library, update the shlibs information.
2. Recompile all the packages that depend on those libraries.
3. Start migrating stuff to libpng3
4. At some point everything is compiled against libpng3 and we keep
libpng2 arround only for compatiblity with other distributions
The annotated version
---------------------
0. Recompile libpng2 and libpng3 with versioned symbols.
"Versioned symbols" means that the dynamic linker can distinguish
between png_do_expand_palette from libpng2 and libpng3 because they
are tagged with a version number. That also means than if the linker
looks for png_do_expand_palette *without a version tag* it will find
it.
Nothing in Debian will break because applications linked against the
old libpng2 or libpng3 will still be able to have their PNG
dependencies resolved (both at package level and symbol level)
Installing these versions on any system where they can installed
doesn't have any immediate side-effect but read on.
1. Recompile all the library packages that link against libpng2 or
libpng3. For each recompiled library, update the shlibs information.
It goes without saying, installing the recompiled versions of these
libraries is not possible on systems without the /versioned/ version
of either libpng2 or libpng3, whatever is required. The usual
dependency mechanisms help here:
Package: libbar
Depends: libpng2 (>> 1.0.12-4)
The shlibs file of these libraries should be modified accordinly
because ...
2. Recompile all the packages that depend on those libraries.
... even if there's nothing special about the newly recompiled
libraries, it is necessary to make sure that all the libraries
linking against libpng2 or libpng3 are upgraded to the versions using
versioned symbols. The reason is...
3. Start migrating stuff to libpng3
... rather simple when you think about it. Since now everything is
using versioned symbols, mixing libraries linking against libpng2 or
libpng3 is not a problem, but only under the assumption that
everything is using versioned symbols. If someone decides to
fast-forward and recompile a library against libpng3 before 1. is
done, you'll have something like this:
Package: foo
Depends: libbar (>> 3.14159-2), libbaz
Package: libbar
Depends: libpng3 (>> 1.2.1-1.2)
Package: libbaz
Depends: libpng2
Which means that stops working with PNG files. Now it should be
clear why the transition can only start at this point. You want to
achieve this situation:
Package: foo
Depends: libbar (>= 3.14159-2), libbaz (>= 2.71828-2)
Package: libbar
Version: 3.14159-2
Depends: libpng2 (>> 1.0.12-4)
Package: libbaz
Version: 2.71828-2
Depends: libpng2 (>> 1.0.12-4)
And here you'll be able to recompile *either* of libbar or libbaz
against libpng3 *whenever* you want.
4. At some point everything is compiled against libpng3 and we keep
libpng2 arround only for compatiblity
When will this happen? Hopefully in a reasonable ammount of time
(before the end of the year would be reasonable).
Reply to: