Please share you suggestions and advice for importing some modular Xorg 
components.

I have been slowly working on packaging up many modular Xorg packages for 
several months now. On some of my Linux, DragonFly and NetBSD systems I 
use them a lot. I have been using many of these components for around 6 
months and more (since I also have been using libX11 and et cetera from 
xlibs for a lot longer).

A few times I have asked some about this, but received little feedback.

Here's the background:

A few of our essential packages are based on sources that get no more 
maintenance. They were from the freedesktop.org xlibs project which was 
mostly just a testing place.

But now, many softwares are requiring the features, headers and libraries 
provided from these dead packages.

This list includes our:

x11/compositeext
x11/xextensions
x11/renderext
x11/randrext
x11/fixesext
x11/Xrandr
x11/Xrender
x11/Xcomposite
x11/Xfixes
x11/xcursor
fonts/Xft2

Newer maintained versions of these are available (from I think the same 
developers) in the modular X.org project. (They have slightly different 
package names, but basically same, but updated, results).

Also related to this is graphics/xpm -- its upstream hasn't been updated 
for years. Modular X.org also has a maintained version. Same with libXaw.

So here's one situation:

Xft2's maintained replacement is libXft. It uses pkg-config by default to 
find its dependencies, but that can be overridden by setting environment 
variables. It needs libXrender.

So I have it buildlink against my x11-links against a native XFree86 on 
NetBSD.

It fails to build later due to missing X11/Xregion.h include file. This is 
provided by modular X.org's libX11 package or from monolithic (which also 
has no maintenance) X.org. It is not provided with our native XFree86. 

Note that I did not check newer XFree86. Also I know we may move to Xorg, 
but that doesn't help other platforms using some other X implementation.

I am assuming that issues like this will probably occur in other places 
too.

I prefer to not create custom packages that I have to maintain myself to 
create this support and I don't want to patch packages to skip the modern 
support. And I don't want us to stay with old unmaintained software.

My working fix is to simply allow it to depend on and install libX11 which 
brings in libXau and libXdmcp. These are installed to /usr/pkg/lib and 
/usr/pkg/include and don't get in the way with same named files. In my 
experience the multiple versions of X11 components works fine. But I can 
imagine that someday, somehow, their will be a conflict in the interfaces 
where the different X implementations end up linking with or using each 
other.

Right now we have builtin.mk files that attempt to figure out if the 
support is available or not for some things. (In addition to Xregion.h, 
the compositeext and fixesext features also do not appear to be provided 
by XFree86.)

Packages that use some of these components include:

pango
cairo
libgdiplus
icewm
seamonkey
gtk2
kdebase3
lesstif
qt3-libs
qt3-libs
xscreensaver

Is it okay to allow libX11 to also be installed? What abouts its 
dependencies? And libXext (needed by libXrandr)?

Does anyone care if they have some of these components installed twice 
(for example they have XFree86's libX11 and modular X.org's libX11)?

I started planning to just replace the header extension files with the 
newer ones, but that breaks things because pkg-config filenames have 
changed for example (like our old Xfixes and fixesext/fixesproto). I don't 
want to patch those too -- only to find out next that there are other 
incompatibilities (like changed API).

It seems it would be best just to replace all these packages (as listed 
at top of this email) at one time. Another reason to do this, is because 
GTK, GNOME, QT developers on nearly all Linux platforms are already using 
these new libraries and headers.

If anyone wants to play with this, see pkgsrc-wip. (I see I need to do 
libXcomposite still.)


 Jeremy C. Reed

p.s. As for me I am phasing out the monolithic X from my systems as it is 
easier in the long run to just update a couple small packages versus 
updating huge monolithic X.