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