[Note: I'm moving this thread to tech-pkg as it's now heavily
infrastructure-related.]

On Sat, Apr 15, 2006 at 09:56:48PM -0700, Jeremy C. Reed wrote:
> 
> 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).

It sounds like these packages are all very well-tested, which is good
to hear.  I'm only concerned about how to integrate the new components
into pkgsrc, hopefully without further perpetuating the problems
experienced with both the monolithic X.org packages and the XFree86
packages.

[snip] 
> 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.

Yes, this is my fear as well, and patching many packages to support
multiple versions of X11 is not the way I would like us to move,
especially as it seems some of those versions will be, at the very
least, de facto deprecated in the not-so-distant future.

> 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.

Yes, I don't think allowing packages to link against multiple versions
of libX11.so is going to work for the reason you state above.  It
would be an especially bad bet to hope that libX11.so maintained by
different projects would keep the same interface for all time.

I think we should overhaul our X11 support in pkgsrc completely.  The
current framework is creaking because it was born in the days where
we only had a native XFree86 on NetBSD, and the subsequent additions
of both XFree86 and X.org into pkgsrc were hacked into the framework
just to make things work, but without addressing any of the underlying
assumptions made by the framework.  It's time to move on, and these
modular X.org packages provide a genuinely good reason to do so.

I think the right thing to do is enforce restrictions based on which
X11 implementation you are using.  If you are using a native X11, then
you may not link against X11 component packages from pkgsrc if those
same components are also supplied by the native X11.  We must treat
monolithic X11 as a standalone piece of software and force "conflicts"
with all X11 component packages.

Here is my N-step plan to make this happen:

(1) Scrap pkgtools/x11-links and create a pkgtools/native-X11 package
    that symlinks everything from /usr/X11R6 into /usr/pkg.

(2) Modify the buildlink framework to drop BUILDLINK_X11_DIR because
    we're just assuming that X11 lives in /usr/pkg.  We modify the
    wrappers so that -[ILR]/usr/X11R6/* are transformed into
    -[ILR]/usr/pkg/*.

(3) Drop support for USE_XPKGEDGE=no.  Handle the XAPPLRESDIR problem
    by having packages that install X11 resource files include a
    post-install action (via the INSTALL script) that symlinks or
    copies the resource file into /usr/X11R6 in the X11_TYPE=native
    case.

(4) Modify the monolithic X.org and XFree86 packages in pkgsrc to
    install directly into /usr/pkg, and not into /usr/pkg/{xorg,XFree86}.
    Make them conflict with each other.

(5) Ensure that that modular X.org component packages install directly
    into /usr/pkg and import all of them from pkgsrc-wip into pkgsrc.

From this point onward, we treat all X11 installations as conflicting
packages that live in /usr/pkg and link packages against the X11
libraries that live in /usr/pkg.

A package would indirectly specify dependencies on X11 component
packages by setting USE_X11 to the components that it needs, e.g.

	USE_X11=  Xft2 Mesa

and then including x11.buildlink3.mk.  The x11.buildlink3.mk file
would take are of including either the correct modular X.org buildlink3.mk
files or the buildlink3.mk corresponding to one of the monolithic X11
packages, depending on the value of X11_TYPE.

We would get rid of all X11-related builtin.mk files as they would be
no longer needed.

Comments?

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>