--nextPart2475355.jE2JCXrSzR
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rex Dieter wrote:
>Couldn't new public symbols be tagged in the shared lib, similar to how
>glibc does it, like:
>libc.so.6(GLIBC_2.1)

glibc does that for multiple versions of the symbols. Not to mark the=20
entry of new ones.

>So, this new kdelibs-3.3.2 symbol would generate a dependancy something
>like:
>libkdecore.so.4(KDE_3.3.2)
>
>If it was done this way, binary compatibility would be seemless, and it
>would make packagers' (rpm, deb whatever) life a lot simpler.
>
>IMO, qt could try do to this to, even between qt-x.y -> qt-x.(y+1)
>upgrades, since the shared lib is the same libqt-mt.so.3

It is much easier said than done. We're dealing with C++ here, and not=20
everything is easily versioned. Imagine, for instance, versioning the=20
virtual table, or the typeinfo. For that matter, remember that C++=20
mandates only one typeinfo, so you can't even think of versioning it.

It would make sense to mark a symbol's entry date to the library, as you=20
proposed. That would readily tag a dependency against its minimal=20
versions.=20

However, not using a newer method doesn't mean you don't require a newer=20
behaviour. That could give a false illusion to developers and packagers.
=2D-=20
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart2475355.jE2JCXrSzR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBr3d2M/XwBW70U1gRAn6bAKCEEokUXfHELQYfWKLYiM8htlYBLgCgj6Ht
IjL6uwp/Cij2c/Os9aF+es8=
=TXRI
-----END PGP SIGNATURE-----

--nextPart2475355.jE2JCXrSzR--