Re: pkgsrc and XAPPLRESDIR

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Nov 14, 2011 at 09:54:44PM +0900, Izumi Tsutsui wrote:
 > >  > Most users don't have any interest in how it works (or sucks)
 > >  > but just want to know what's required to make it work.
 > >  > 
 > >  > So my suggestion is to apply patch in xsrc/26357, or
 > >  > add a MESSAGE file that mentions XAPPLRESDIR for pkg_add users.
 > > 
 > > As already pointed out, there'ss already a MESSAGE.
 > 
 > At least "pkg_add kterm" doesn't show anything about XAPPLRESDIR.
 > http://mail-index.NetBSD.org/tech-userlevel/2011/11/14/msg005778.html

Ok, I thought that message was going to end up in the binary package.
If it doesn't, it certainly should.

 > > There are 108 packages whose PLIST matches lib/X11/app-defaults/.
 > > Most of them are ancient things unlikely to get major updates from
 > > upstream, so patching them isn't necessarily infeasible or reckless.
 > > 
 > > However, I thought of what might be a better way... is there an Xt
 > > call that can load an app-defaults file such that the resources get
 > > handled with the right search priority? Because if so, we can probably
 > > solve the whole problem with some shared library hacks.
 > 
 > I'm not sure if I see your point, but isn't that what PR/26357 claims?

No. The PR has a patch to hack libXt to add the app-defaults dir in
/usr/pkg to the default app-defaults path. There are a bunch of
reasons (most of them outlined near the top of the PR) why that's a
hack.

What I'm talking about is arranging for xpkgwedge-compiled packages to
call into libXt to add the pkgsrc app-defaults directory to the
app-defaults search path dynamically, or at least add it to some
suitable search path for Xt resources. The problem is that the lookup
order for Xt resources is complex and fragile and if you insert the
program's app-defaults file into the wrong place in it things will
break. So I was asking if any suitable libXt call exists.

If one does, this method will work on any ELF platform for any
$PREFIX; if we have to add one it'll only work with NetBSD's native X
and pkgsrc X, which is much less desirable but still better than
nothing. But even then it'll at least adapt to the proper $PREFIX.

(What I have in mind is to (ab)use the ELF dynamic linker's "wrap"
feature to intercept XtAppInitialize.)

My inclination remains to go ahead and patch the 108 packages though.
Most of them also use imake and that too should be ripped out.

-- 
David A. Holland
dholland%netbsd.org@localhost