Re: [PATCH] gnu: Add whois.

[ng0]

Marius Bakke <address@hidden> writes:

> ng0 <address@hidden> writes:
>
>>> * The Debian package is built with HAVE_ICONV=1, should we set that too?
>>
>> I can send an updated patch with libiconv in the inputs. This is when
>> you use a libc which does not provide a (usable) iconv, which is why
>> Gentoo provides the option to build it with this too. As we are
>> _currently_ only providing options to do one libc globally this is not
>> so inmportant. I will even build uclibc-ng (I am working on that) with
>> an outside iconv because reportedly their iconv is in bad shape.
>>
>> So with this information, should I send a new patch which adds libiconv
>> and the build option?
>
> Since we only support glibc at the moment, I don't think adding a
> package for libiconv first is necessary. On the other hand, if it can
> cause problems on other libc's, it's nice to use an external one.
>
> IMO adding libiconv as input is something that can be done later, when
> there is an actual need for it. I guess there are more packages that
> will require it. But I don't really mind either way :)
>
>>> Additionally it installs locales, but looks for /usr/share/locale at
>>> runtime. Fixing this would probably require upstream help, I don't want
>>> to hardcode either "/run/current-system/locale" or ~/.guix-profile. The
>>> current version probably works on foreign distros, if nothing else.
>>
>> If you know how to fix it, try to bring it to upstream or include a
>> patch / substitute phase at our end?
>
> I tried patching whois.c to use the glibc default in the call to
> bindtextdomain(3), instead of the LOCALEDIR build option. That almost
> worked: it searches the system locales, but also expect to find the
> translation files there. I'll see if I can cook up a fix for upstream,
> but don't think this should hold back the package.
>

I think we can bundle the patch until it/if gets accepts at all by
upstream.