On Fri 16 Nov 2018 at 22:11:14 +0100, Joerg Sonnenberger wrote:
[about using the pkgsrc version of gettext-tools, which depends on
gettext-libs, which includes libintl, which must not be linked into the
same program as the base system libintl]
> It still ensure that the library is installed and that one can create
> various fun. Little reason for that given that the two files are
> essentially static.
That is true, but only in the build environment. In the runtime
environment, the intl library isn't there. (This is assuming that one
uses binary packages somehow, either downloaded, or built in pkg_comp,
or something along those lines).
The problem with pre-generating some files and adding them to files/ is
that it doesn't scale.
Not only doesn't it solve other packages which have similar issues, it
also doesn't solve the problem for the package itself. On every update,
the maintainer (or other updater of the package) must *somehow*
re-generate these files. And do this while generating these files has
been carefully and thoroughly disabled. So it is a pain to do. And
what's worse, the updater has to know that it has to be done and
remember to do it. This is probably even a bigger problem, since it
doesn't fit within the standard updating procedure.
Before I come back to this, I had a better look at www/lynx. It was the
only package that I have that run-time-depends on gettext-tools. It has
this in www/lynx/Makefile:
.include "../../devel/gettext-tools/buildlink3.mk"
I didn't see any pressing need for this, so I tried removing it. This
mostly went well except for this during build:
msginit --no-translator -l en -i lynx.pot
/bin/sh: Can't open /usr/share/gettext/project-id
msginit: /usr/share/gettext/project-id subprocess I/O error
Created en.po.
When I added
TOOL_DEPENDS+= gettext-tools>=0.19:../../devel/gettext-tools
this error was gone. Lynx still didn't link in the wrong libintl.
(For cleanliness I should probably also have removed msginit from
USE_TOOLS and set CONFIGURE_ENV+=MSGINIT=${LOCALBASE}/bin/msginit)
So there is indeed in practice another package with the same problem to
solve. The solution has to scale at least a little bit.
In fact there seem to be lots of other packages which may have the same
risk of inadvertently linking in the pkgsrc libintl. Candidates to look
at and probably make consistent are (as found by grep gettext-tools):
cad/pcb, cad/geda, which DEPEND on gettext-tools;
devel/quilt which USE_TOOLS it;
finance/gnucash, x11/gtk3 which TOOL_DEPENDS on it;
devel/confuse, graphics/exiv2, mail/neomutt, sysutils/amanda-common,
sysutils/dvdisaster, www/webkit-gtk, x11/redshift,
multimedia/kodi, multimedia/minidlna,
which BUILD_DEPENDS on it;
devel/kdesdk-thumbnailers, devel/poxml, editors/gtranslator,
graphics/blender, inputmethod/fcitx, shells/fish, textproc/po4a,
which buildlink it;
graphics/gimp-docs-pl which does _TOOLS_USE_PKGSRC.msgfmt=yes
sysutils/dfc does BUILDLINK_DEPMETHOD.gettext-tools?=build and
buildlinks it.
(and more packages in wip/ which also use several of the above patterns)
"Fixing" all of these by adding the burden of pre-generating some files
for them for each version update on the respective maintainers doesn't
sound good to me.
So I still think we either need a 1-or-2 line fragment to copy into each
of these packages, or indeed even try for some other solution in the mk/
directory which uses the right tools and prevents linking the wrong
library.
Compared to my initial attempt, essentially
TOOL_DEPENDS+= gettext-tools>=0.19:../../devel/gettext-tools
with MSGFMT set so configure uses the right version
I like the looks of
USE_TOOLS+= gettext-tools
even better because it seems to express more directly what the package
wants. Strangely enough though it doesn't add a tool dependency on
gettext-tools so we can't use that here.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power
\X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
Attachment:
signature.asc
Description: PGP signature