On Tue, Mar 05, 2002 at 11:59:54AM +1000, Anthony Towns wrote: > Joseph, I'm really sorry about this, but the time when you get to make > ABI changes like this really is over. The current SDL packages are unreleasable. Have you taken a look at the reverse dependencies for SDL recently? Reverse Depends: libsdl1.2-dev,libsdl1.2debian 1.2.3+cvs20020303-0 egoboo,libsdl1.2debian libsdl1.2-dev,libsdl1.2debian 1.2.3+cvs20020303-0.1 ohphone,libsdl1.2debian maelstrom,libsdl1.2debian zsnes,libsdl1.2debian sarien,libsdl1.2debian quake2,libsdl1.2debian prboom,libsdl1.2debian gtktiemu,libsdl1.2debian gnuboy-sdl,libsdl1.2debian exult,libsdl1.2debian aranym,libsdl1.2debian xsabre,libsdl1.2debian xmms-jess,libsdl1.2debian 1.2.2-3.1 xmms-infinity,libsdl1.2debian vlc-sdl,libsdl1.2debian vectoroids,libsdl1.2debian tuxtype,libsdl1.2debian tuxracer,libsdl1.2debian toppler,libsdl1.2debian synaesthesia,libsdl1.2debian smpeg-xmms,libsdl1.2debian smpeg-plaympeg,libsdl1.2debian smpeg-gtv,libsdl1.2debian rocks-n-diamonds,libsdl1.2debian pysol-sound-server,libsdl1.2debian pygame,libsdl1.2debian pipenightdreams,libsdl1.2debian penguin-command,libsdl1.2debian noatun-plugins,libsdl1.2debian moon-lander,libsdl1.2debian mirrormagic,libsdl1.2debian marbles,libsdl1.2debian mangoquest,libsdl1.2debian madbomber,libsdl1.2debian libsmpeg0,libsdl1.2debian libsdl1.2-dev,libsdl1.2debian 1.2.2-3.4 libsdl-ttf1.2,libsdl1.2debian libsdl-ruby,libsdl1.2debian libsdl-perl,libsdl1.2debian libsdl-mm0.1,libsdl1.2debian libsdl-mixer1.2,libsdl1.2debian libsdl-image1.2,libsdl1.2debian libpolhem,libsdl1.2debian libopenal0,libsdl1.2debian libgengameng3,libsdl1.2debian libdv-dev,libsdl1.2debian libavifile0.6,libsdl1.2debian lgeneral,libsdl1.2debian lbreakout2,libsdl1.2debian ksmp3play,libsdl1.2debian ketm,libsdl1.2debian jumpnbump,libsdl1.2debian icebreaker,libsdl1.2debian heroes-sdl,libsdl1.2debian gltron,libsdl1.2debian gemdropx,libsdl1.2debian ganso,libsdl1.2debian frozen-bubble-lib,libsdl1.2debian freesci,libsdl1.2debian falconseye,libsdl1.2debian egoboo,libsdl1.2debian dossizola,libsdl1.2debian defendguin,libsdl1.2debian csmash,libsdl1.2debian criticalmass,libsdl1.2debian crimson,libsdl1.2debian coriander,libsdl1.2debian circuslinux,libsdl1.2debian chromium,libsdl1.2debian castle-combat,libsdl1.2debian burgerspace,libsdl1.2debian bumprace,libsdl1.2debian bugsquish,libsdl1.2debian black-box,libsdl1.2debian avifile-samples,libsdl1.2debian avifile-player,libsdl1.2debian armagetron,libsdl1.2debian amphetamine,libsdl1.2debian achilles,libsdl1.2debian abuse-sdl,libsdl1.2debian Shall we then remove ALL OF THAT from woody because a non-incompatible ABI change is too much to ask for and the package been in need of a maintainer for so long? On the other hand, I am fairly certain that none of the packages in woody will need recompiling to work with the packages as they are right now. I can only be fairly certain as I have only tested or heard reports of about 1/3 of them so far. My packages do not provide compatibility for the extra --*-libs options Branden added in October because at that time I was uncertain if it would not be necessary to recompile everything or not. Now that I can see that it is not, I can add the extra flags within half an hour, including build and testing time. Had a recompile of everything been found necessary, I could understand your objections. But this change so far requires a recompile of NOTHING, and before I upload the packages, the --*-libs options will also be present. This is a far less-reaching change than the changes you were discussing today regarding the various libdb's, and happens to fix with one wishlist exception, every single bug which has been filed against any of the SDL packages. > > This isn't some haphazard change just because a couple of maintainers and > > an upstream author felt inclined to suddenly break things. It's a quickly > > planned and executed change which fixes non-Debian binaries in most cases > > that they possibly could be fixed, and probably does not break one single > > package in Debian. I say probably because I have not (yet) personally > > tested them all. > > And there's the problem. Everything seems quick and easy until you start > to roll it out across eleven archictectures and a few dozen packages. I can pretty much guarantee these packages break nothing that was not already broken. And they fix a number of things that were. If anything at all holds up woody at all, I am absolutely certain it shall not be my SDL package's fault. > I invite you to reread the message posted to -devel-announce way back > in November: > > http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200111/msg00006.html > > Library ABI changes aren't worth the price anymore. Do you not understand the exact nature of the ABI change? On other dists, SDL links the three XEL's into the shlib, this is a major nono on half the archs Linux runs on. (Some link them as shlibs, which is just broken and can/will not be addressed by my packages - Red Hat's problem, not mine,) Debian's packages do NOT have this broken behavior anymore. ALL of our packages have been fixed to cope with the change already. There is no transition needed; it was made in October. All Debian binaries tested so far with these packages, including on some of the archs which were broken before the October fix, work fine. The ABI change only affects non-Debian binaries, which did not work before and may suddenly start working now through the magic of our SDL packages no longer requiring the binary be linked with the XEL's to satisfy its own symbol needs. The solution used was chosen to break as few binaries which already exist as possible. Only those which are otherwise already quite broken will fail to work with these packages. They are literally as safe an upgrade as is possible, though last night I could not have been certain of that. Further, let me quote your own reference: > To emphasise: if you want a pleasant, consistent, bug-free woody > release, please start looking at the bugs in your favourite packages and > sending the maintainer patches for them *now*. A number of the bugs > above will need some real analysis, not a five minute tweak. This coming > weekend is a bugsquash party, so hopefully many of the above will end up > fixed soon. I just did exactly that. These packages address every single bug, RC or not, that can be addressed without an impact on woody. Those which are not fixed cannot be fixed before woody without the possibility of making things more complex for the woody release. Realize who you're talking to a moment. Has any other developer bitched about the lack of a more current stable release than I in recent months? I somewhat doubt it. I have absolutely no intention of doing anything to these packages which will hold up the woody release. That is the precise reason for the big warning message and test period to make damned sure that when I _do_ upload these packages, they Just Work(TM). -- Joseph Carter <knghtbrd@bluecherry.net> Sanity is counterproductive <Endy> taniwha: Have you TESTED this one? :) <taniwha> Endy: of course not
Attachment:
pgpH97WgBhcto.pgp
Description: PGP signature