RFC: What to do with the stale/buggy Xft/Xrender in the tree.
Mon, 01 Mar 2004 21:09:11 -0800
Content-Type: text/plain; charset=utf-8
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.3.1 11/28/2001
-----END PGP SIGNATURE-----