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

[Mike A. Harris]

The current Xft and Xrender that are in the XFree86 and X.org 
source trees, are several releases behind their upstream official 
versions.  The new releases are bug fix releases, and fix several 
issues reported by people.  I don't believe there is new 
functionality included, but Keith would be the authority on that.

The crux of the problem, is that we would like to upgrade Xft and 
Xrender to the latest versions available so that people who use 
the new tree do not experience bugs that have been fixed already 
now for 3-12 months or more in Keith's upstream Xft/Xrender.

Normally, we would just import the new libraries into the tree 
and clean up the merge and be done with it, however this can not 
easily be done currently, because the upstream Xft and Xrender 
have been autotooled now, and libtool generates 3 digit .so 
version numbers which imake is not capable of generating on it's 
own.  ie:  libXft.so.2.1.2

A few months ago, I was tasked to update Xft and Xrender in our
Red Hat XFree86 packaging and encountered this problem.  After
attempting several different ways to solve the problem, I
realized there really was no "clean" solution to do this in the
XFree86 source tree, and doing it in separate Xft/Xrender
packaging was not an option I could persue at the time, for
distribution engineering reasons.

As such, I decided to go with a quick dirty hack.  My solution 
was to remove the included Xft/Xrender, and untar the new 
upstream versions in their place, tweak the Imakefile a bit, and 
let imake build it in tree normally.  After the entire X build is 
complete, I manually sledgehammer the .so versions in my rpm spec 
file so that they match Keith's upstream.  As I said - an ugly 
hack, but it did the job for our purposes.

Now, since we'd like to officially upgrade Xft and Xrender in the
monolithic tree itself, we are faced with this same problem, and
while my ugly distribution specific rpm specfile hack could be
reimplemented with some Imake whackiness, it isn't the best 
solution in the world, and would very likely have some 
portability issues.

After discussing the various problems in IRC and on the phone 
with Keith, Jim, and a few others, we brainstormed a number of 
possible solutions, and some of the advantages/disadvantages of 
each.  Then, we tried to select the solution which met as 
many of the following goals as possible:

- we want people to use the newest Xft/Xrender available, so they 
  are not using stale bits, and not encountering or reporting 
  bugs which have been long since fixed in upstream.

- we do not want to break their systems, cause incompatibilities

- we do not want people to compile the sources, install them, and 
  then have the Xft using applications included in the monolithic 
  build fail to work.


Here are the 6 solutions brainstormed, along with comments about 
each solution:

1) Remove Xft and Xrender from the tree entirely.

Problems: 

- This would stop xterm, xclock, and xditview from building, as
  they currently require Xft.  We would have to disable them from
  building by default.


2) Replace stale Xft/Xrender with new upstream version.

Problems:
- We can't do this correctly as imake can't create .so files 
  with the right versioned extension.
- While there are a few ugly hack methods that might work, they 
  would be very ugly and prone to be problematic, and highly 
  likely to be non-portable.


3) Do not update Xft/Xrender, instead just leave them stale, as 
they currently are.

Problems:
- This is bad because broken bits will be installed, thus 
  leading to users reporting bugs that are long since fixed.
- It also may cause conflicts if a user already has a newer 
  upstream versions of Xft/Xrender installed, and the older 
  monolithic version gets installed.  Having dealt with user bug 
  reports caused by similar problems with freetype in the past, 
  this is a very bad idea.


4) Leave Xft/Xrender sources stale, build them so that 
xterm/xditview/xclock can build in tree, but then do not 
install the stale Xft/Xrender.

Benefits:
- This would work, because the upstream libraries are ABI 
  compatible.

Problems:
- If someone does manage to install them, "bad things" happen.
- If someone does not already have upstream Xft and Xrender 
  libraries installed, then they will build the monolithic X 
  build ok, however once it is installed, xterm/xclock/xditview
  will not run because the Xft and Xrender libraries were
  excluded from the installation process intentionally.  This is 
  a very bad idea and would create much confusion.
- For joe blow who downloads and installs, it would create a
  flood of "xterm doesn't work" problems in bugzilla/email/etc.


5) Stub them out.  Remove the implementation leaving only the
   public interfaces, and those with empty function bodies.

Problems:

- This would work just as #4 above, but ensures that the
  libraries would not actually get used, or someone would notice
  right away for sure.
- Same problem as above, where built apps wont work on installed 
  system unless upstream libXft/Xrender are installed.
- For joe blow who downloads and installs, it would create a
  flood of "xterm doesn't work" problems in bugzilla/email/etc.


6) Leave the stale libraries in, but don't build them by default.
   Add new Imake config defines "HasXft" and "HasXrender", both 
   defaulting to "NO", and "UseXft" and "UseXrender" also
   defaulting to "NO".  Modify xterm/xclock/xditview so that they 
   build by default *without* Xft support, unless it's enabled 
   using one of the above defines - explained below.

Benefits:
- If the person building X has upstream Xft and Xrender installed 
  on their system already, they can then enable "HasXft YES" and 
  "HasXrender YES" in host.def or wherever they normally tweak 
  the build configuration.  That will cause the included xterm, 
  etc. to build with Xft support, linking to the system-supplied 
  libraries.  If just "HasXft" is defined to YES, it will imply
  "HasXrender YES" also unless it's been explicitly defined to 
  NO.
- If the person building X does NOT have upstream Xft/Xrender 
  installed, they can opt into using the included stale 
  Xft/Xrender anyway, by enabling "UseXft YES", which will 
  implicitly enable "UseXrender YES" also, and cause the 
  stale libraries to get built and used anyway.
- If the apps get linked to the stale libraries, and the user 
  later upgrades Xft/Xrender somehow, the apps will work because 
  there is ABI compatibility.
- This seems to be the least hackish solution of all of the 
  above.
- Each OS platform/vendor can set the $vendor.cf file to default 
  to what works best for their platform by default.

Problems:
- On systems that do not have libXft/libXrender installed 
  already, by default, the included apps will build without Xft 
  support.  All in all, not a major loss, and it is resolved 
  easily enough by installing upstream Xft/Xrender, or tweaking 
  the host.def
- Not sure how much effort - if any, would be required to make 
  these apps build with conditionalized Xft support.



After our discussion in IRC, we currently believe that option #6
above is the least disruptive of them all, and provides the most
amount of compatibility, while making the defaults sane for each
OS platform.  I would like to get some technical feedback from
Egbert and others about the above solutions, and try to come to a 
concensus soon, so that the work to clean this up can get in tree 
ASAP.

Thanks in advance.