Re: gettext-tools with g-prefix (was Re: xgettext with UI files support)

[Richard PALO <richard%netbsd.org@localhost>]

Le 26/09/15 20:31, Richard PALO a écrit :
> I added back the TEST_TARGET and put in build depends for some required packages to test.
> 
> Naturally I came across a bug that is fixed in the recent 0.19.6 so I also do an update here
> rather than adding a patch.  
> 
> Please see updated: http://www.netbsd.org/~richard/gettext-tools.patch
> 
> I needed to adapt a bit the post install symlinks, as I noticed during `bmake replace' not liking them,
> giving the following sort of messages:
>> Creating package /tmp/pkgsrc/devel/gettext-tools/work/gettext-tools-0.19.4nb1
>> Full pathname symlink `/opt/local/bin/gautopoint' is target of `/opt/local/gnu/bin/autopoint' - adjusting to `../../bin/gautopoint'
> ...
> 
> and
>> ===> Updating using binary package of gettext-tools-0.19.6
>> /opt/local/sbin/pkg_add -K /opt/local/pkg -U -D /tmp/pkgsrc/devel/gettext-tools/work/.packages/gettext-tools-0.19.6.tgz
>> gettext-tools-0.19.4nb1: unregistering info file /opt/local/info/gettext.info
>> symlink Symlink:../../bin/gautopoint is not same as recorded value, not deleting: /opt/local/gnu/bin/autopoint
> ...
> 
> If this is correct, then perhaps the other gnu utils (coreutils, binutils, gmake, etc) may
> need an update as proposed in this patchset.
> g

Two things, 

1. I'll update the symlinking to use ${PKGMANDIR} instead of 'man' 

2. But there seems to be a potential problem with using PKGGNUDIR in the symlinks in that it could be "" (or something else)
   instead of "gnu/", changing the relative base.
  
   Isn't there a way to leave the full specification in the packages and have bsd.install.mk 'record' the right "relative"
   path instead?

Observations?
-- 
Richard PALO