Re: pkgsrc and XAPPLRESDIR

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

dholland-tech@ wrote:

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

Well, then what's your conclusion?

You have an idea, but no code?
PR/26357 is unacceptable even for interim fix and
we should just add MESSAGE files to 108 packages?
---
Izumi Tsutsui