[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Preliminary SDL 1.2.3+cvs packages available



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: pgpvVCvFEnDh_.pgp
Description: PGP signature


Reply to: