Subject: Re: Overhaul X11 handling [was Re: need advice for integrating modular Xorg libraries and headers]
To: None <tech-pkg@NetBSD.org>
From: Dieter Baron <dillo@danbala.tuwien.ac.at>
List: tech-pkg
Date: 04/21/2006 02:31:35
In article <20060420141938.GA1705@NetBSD.org> Johnny wrote:
hi,
: 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.
Yeah, another buttload of symlinks. What exactly does that buy us?
Not having to pass -L/usr/X11R6 to the linker? Is that importaint
enough to clutter up ${LOCALBASE}/bin with all those X11 binaries?
: (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.
I don't think pkgsrc should install into /usr/X11R6. I thought that
was the whole point of USE_XPKGWEDGE.
: 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.
So when using native X11, one would not be able to install a package
that needs a component not provided by that native X11?
yours,
dillo