RFC: What to do with the stale/buggy Xft/Xrender in the tree.

[Keith Packard]

--==_Exmh_1558442457P
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit


Around 16 o'clock on Mar 1, "Kaleb S. KEITHLEY" wrote:

> It shouldn't be hard to fix imake, or more accurately, lnxLib.rules, to 
> deal with teeny library revs. That's probably useful in the general 
> sense. Although it'll break when some genius decides he needs four 
> levels of versions on a library.

"shouldn't be hard" == "not in this release timeframe"...

> What part is non-portable?

Libtool has mystic semantics for version numbers on a variety of systems.
This makes it difficult to ensure that .so version numbers will match
between imake and libtool.  I had code added to libtool 1.5 to make it
possible to ensure library version matches to two digits for the core X
libraries (the --version-number flag).  I don't believe that provides much 
assurance about the third digit on various systems.

> I missed that discussion (because I can't be on IRC 24×7) but I'd rather 
> see lnxLib.rules fixed to deal with three-level versions and install 
> current bits.

I'm not sure we can fix up all of the Lib.rules files without quite a lot 
of testing.

What we can do is let distributions disable installation of the libraries, 
update the code to current released bits and leave it at that.  The 
released versions all have third digits which should make them preferred 
on Linux systems.

-keith



--==_Exmh_1558442457P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.3.1 11/28/2001

iD8DBQFARBb3Qp8BWwlsTdMRApo8AKCZriWluz4lyKllWqVQME8FDRF8UACg0fGK
QaX+wNe7lFCMO+d0oEDdq6g=
=eb5a
-----END PGP SIGNATURE-----

--==_Exmh_1558442457P--