tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgsrc and XAPPLRESDIR



>>>>> On Mon, 14 Nov 2011 13:24:06 +0000,
      David Holland <dholland-tech%netbsd.org@localhost> said:

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

Why do you think such message is good enough?
If it's enough why does our /bin/sh have to know /usr/pkg/bin?

        $ strings /bin/sh | grep /usr/pkg
        PATH=/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin

IMHO, our default installation should know /usr/pkg, and programs
in the base system are already doing so.

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

It's not a hack, but a well-known configuration for OSes which install
X11 based things to non-standard directories, that's why it can be
defined by an imake macro.

> There are a bunch of reasons (most of them outlined near the top of
> the PR) why that's a hack.

Which part of the PR do you mean?
If you mean what tron@ said, he agreed to apply the patch at the end
of the PR.
-- 
soda


Home | Main Index | Thread Index | Old Index