Subject: need advice for integrating modular Xorg libraries and headers
To: None <pkgsrc-users@NetBSD.org>
From: Jeremy C. Reed <firstname.lastname@example.org>
Date: 04/15/2006 21:56:48
Please share you suggestions and advice for importing some modular Xorg
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:
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
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
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
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
Packages that use some of these components include:
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
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.