hi,

> >: (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?
> 
> Yes, I think it is.  The pkgsrc infrastructure does a lot of work to try 
> to keep track of exactly where binaries and libraries are coming from, 
> and it would simplify things if that were not needed.  I can try to 
> continue keeping track of this information, but I may punt on this if it 
> is too hard.

  What exactly is the problem with x11-links, and how does native-X11
solve them?

  [To take this trend to extremes: when are we symlinking all of /bin,
/usr/bin, /sbin, /usr/sbin, /lib, /usr/lib, into ${LOCALBASE}?]

> >: (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.
> 
> Like some other parts of the INSTALL scripts that do destructive actions 
> outside of ${PKG_PREFIX}, this would be governed by a yes/no variable 
> PKG_INSTALL_XAPPLRES that defaults to "no", but that can be set to "yes" 
> during pkg_add.  Quite frankly, I saw no other general solution to PR 
> pkg/28510 -- modifying xsrc, union mounts, and wrapping every X11 binary 
> are all pie-in-the-sky ideas compared to just putting the X11 resource 
> files where X expects to find them.

  Okay, that sounds reasonable.

  However, while there is a reasonable place to set these variables
for source builds (/etc/mk.conf), there is no such place for adding
binary packages (environment variables are too volatile).

  What about a file that pkg_add reads where these variables
(PKG_INSTALL_XAPPLRES, PKG_INSTALL_RCD, et al) can be set, maybe
/etc/pkgtools?  I think parsing /etc/mk.conf would be more difficult
than it needs to be.  Maybe we could make bsd.pkg.mk parse that file,
too, before reading in /etc/mk.conf.

> >: 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?
> 
> No, when using native X11, a package will not be able to depend on a 
> pkgsrc version of a component that is also provided by the native X11. 
> This is a function of how "big" your native X11 installation.

  I see.  And if a package needs a newer version of a component
provided by native X11, the user is out of luck?  I guess that's hard
to avoid.

					yours,
					dillo