[Those of you not reading this on debian-devel, please see the end of
this mail.]
I am declaring my intent to NMU five shared library packages at once.
Before embarking on this unusual procedure I thought I'd better post the
whys and wherefores in a public place (as well as, of course, contacting
the package maintainers).
I have spoken with the release manager, Anthony Towns, about this, and
he agrees with the nature of the changes being undertaken. Anthony, if
you have any remaining concerns, please let me know.
BACKGROUND:
The problem at issue basically stems from 4 facts:
1) Some of the X extension libraries (namely libXxf86dga, libXxf86vm,
and libXv) are available only as static libraries. This is because
XFree86 wants these libraries available only in static form, and our
practice of shipping them this way is compliant with a Debian policy
proposal ratified in August[1].
2) On about half the architectures in Debian (hppa, ia64, m68k, mips,
mipsel, and powerpc), it is not legal to link static objects into shared
ones. The linker will bomb at compile time if you attempt to do so.
(Yes, you can compile static objects with -fPIC to get around this
problem, but they should not be built this way, and to do so violates
Policy 11.2.)
3) The sdl-config program in the libsdl1.2-dev package outputs
"-lXxf86dga -lXxf86vm -lXv" when called with the "--libs" option on the
aforementioned architectures (but not, e.g., on i386). This is half of
an erroneous attempt to fix a bug reported against the SDL library[2]
involving the above two libraries.
4) The SDL library includes the Xxf86dga, Xxf86vm, and Xv static objects
in its shared object on the half of the architectures in Debian that
permit this, including i386. This is the other half of an erroneous
attempt to fix the bug report mention in 3).
THE PROBLEM:
On half of the architectures in Debian (hppa, ia64, m68k, mips, mipsel,
and powerpc), the following packages and their dependencies are
unbuildable:
gengameng
sdl-image1.2
sdl-mixer1.2
smpeg
On ia64, the approximate number of packages affected by this problem is:
16 Dependencies: libsdl-mixer1.2-dev
6 Dependencies: libsdl-image1.2-dev
4 Dependencies: libsmpeg-dev
1 Dependencies: libsmpeg-dev (>= 0.4.3-2)
1 Dependencies: libsmpeg-dev (>= 0.4.2-2)
1 Dependencies: libsdl-image1.2
1 Dependencies: libgengameng-dev
With a couple of dozen unbuildable source packages, it is difficult for
these architectures to reach the 90% mark necessary for their release as
part of woody[3]. Furthermore, build percentages aside, it doesn't seem
to make a lot of sense to deprive users of those architectures of these
packages if there isn't a good reason to do so.
"So why are they broken?"
In practice, just about everything that builds against the SDL libraries
determines its linkage by calling "sdl-config --libs". This works fine
on i386 and a few other architectures, because the static X extension
libraries are already in the SDL library itself (though it would have
been less harmful, as we will see, to have left the "-lXxf86dga
-lXxf86vm -lXv" flags in sdl-config's output on *all* architectures).
On the other architectures, though (hppa, ia64, m68k, mips, mipsel, and
powerpc), this only works for packages that contain *only* executables
that build against libSDL. If you try to build a library package
against SDL on these architectures, the build will crash when the
library is linked, because those "-lXxf86dga -lXxf86vm -lXv" flags are
present, and you can't link a static object into a shared object on
these architectures.
As a complicating factor, invocation of sdl-config is buried inside
autoconf macros in all the shared library packages I've mentioned.
THE SOLUTION:
1) I have added a "--library-libs" option to sdl-config. "--libs" now
issues the same output it used to (including the static X extension
libraries), and issues the same output on all architectures.
2) A new autoconf symbol has been added. In addition to the existing
@SDL_LIBS@ substitution, there is also @SDL_LIBS_FOR_LIBS@, which is
what library authors should use instead of @SDL_LIBS@.
(In other words, @SDL_LIBS_FOR_LIBS@ should appear in _LIBADD rules in
Makefile.am's, and @SDL_LIBS@ should appear in _LDADD rules.)
3) sdl-image1.2, gengameng, and smpeg have been changed to use
@SDL_LIBS_FOR_LIBS@.
4) smpeg has a tool called smpeg-config which works like sdl-config;
therefore, it has been changed similarly to SDL as described in points
1) and 2) above.
5) sdl-mixer1.2 has been changed to use @SMPEG_LIBS_FOR_LIBS@.
6) Here's the really painful part. The shared library packages in
libsdl1.2 have been changed. Yes, I know, this really really really
really sucks, but it has to happen, and Anthony Towns signed off on
this. Here's why.
Remember when I said above that it would have been less harmful to not
put the X static extension libraries in SDL itself? When the decision
was made to do that -- and to keep executables from linking against the
static X libraries themselves on the half of Debian that includes i386
-- it basically amounted to adding those libraries into SDL proper, as
if the library had been changed. Anyone who is familiar with shared
libraries will tell you that you can add symbols, but removing them is
an incompatible interface change.
And that's exactly what we have here. All SDL-dependent packages on
i386 (and alpha, and sparc, etc.) are expecting to be able to resolve
the symols in Xxf86dga, Xxf86vm, and Xv by looking in libSDL.so.1. But
they won't find them there now. The executables are expected to link
the static libraries themselves. So, in order for Debian's shlibdeps
mechanism to keep people from getting "unresolved symbol" errors from
the dynamic linker when running their favorite SDL-based program, the
name of the shared library package had to change.
I struggled to come up with a name that would make it clear that what we
have is really libsd1.2, and not some fork or beta version. That's
almost impossible to do, but I settled on "libsdl1.2debian". Yes, I
know, it sucks, but keep in mind that we're in this fix in the first
place because we *ALREADY* forked the SDL library to include the static
X extension libraries -- on half of our architectures.
THE IMPACT:
The Good: SDL and all the dependent packages will now be buildable on
all of Debian's architectures, instead of just half. If they're coded
portably, they should actually work on those architectures, too.
The Bad: The new SDL shared library packages Conflict with and Replace
the previous ones. Everything currently built against libsdl1.2 will
have to be recompiled. *THIS WILL NOT REQUIRE CHANGES TO THE SOURCE
PACKAGE*. All you have to do, if you maintain an SDL-dependent package,
is rebuilt it with the new libsdl1.2-dev installed on your system.
(Once this is actually available in the archive, an announcement will be
sent.) sdl-config --libs will work just fine, as it did before. Again,
you do not need to change the source package at all, any more than you
would need to for a binary-only NMU. However, since the same rebuild
will have to happen for half the architectures, I recommend doing a
regular release, or regular NMU for packages that aren't maintained.
This way the build-daemons will do most of the work.
Because the new libsdl1.2debian package will force libsdl1.2 off of the
system, anything still linked against libsdl1.2 will be removed by apt.
It may be a good idea for people who make heavy use of SDL-dependent
packages to put libsdl1.2 on hold until the transition is complete. How
long that takes depends largely on the maintainers of those packages.
THE CODE:
The packages I intend to upload have been built and tested on ia64
(which has the can't-link-static-objects-into-shared-ones problem) and
i386 (which does not). I tested with two packages, which I do not
intend to NMU at this time, lbreakout (links against libsdl1.2debian),
and mirrormagic (which links against sdl-mixer1.2, which itself links
against smpeg, which links against libsdl-image1.2, which links against
libsdl1.2debian).
These packages are available at:
http://hackers.progeny.com/~branden/SDL_OVERHAUL/
I would *VERY* much appreciate feedback on these packages, especially if
you find something seriously wrong with them. However, as far as I can
tell they work just as well as the existing packages, and have the added
virtue of being buildable on twice as many architectures as before.
Thanks for your attention.
RELEASE MANAGER AND PACKAGE MAINTAINERS:
It would be least disruptive if all of these shared library packages
were installed into the archive on the same day. I'd like your blessing
to do an NMU of each of them. I'll accept full responsbility for any
breakage I cause as a result. Anthony, could you please let me know
what day would be good for the big transition?
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100346
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=104344
[3] http://buildd.debian.org/stats/
--
G. Branden Robinson | Mob rule isn't any prettier just
Debian GNU/Linux | because you call your mob a
branden@debian.org | government.
http://people.debian.org/~branden/ |
Attachment:
pgpsDJFdXZ0He.pgp
Description: PGP signature