pkgsrc-Users archive

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

Re: converters/libiconv-1.16

On 11.10.2019 14:56, Greg Troxel wrote:
> Kamil Rytarowski <> writes:
>> ./ picks /usr/pkg/include (or $PREFIX) paths by default as they
>> are detected by autoconf. I don't remember ofhand the reason for it, it
>> could be pkg-config that is used by ./ tools.
> So perhaps should not use pkgsrc paths.
>> It would be ideal to blacklist packages from pkgsrc that interfere with
>> the process of bootstrapping tools.
> Do you mean:
>   change not to look at them
> or
>   ban them from pgksrc?
> The second seems unreasonable.

As long as the former is not addressed, I have personally the latter
rule in effect. If libiconv will be picked for more software it will be
harder to avoid it and this is not wanted for me locally.

As a general rule please try to reuse native iconv() whenever possible.
It's comparable to picking native sed(1) instead of forcing gsed for no
good reason.

>> Before that, libiconv causes harm as /usr/pkg/include is in the search
>> path, and prior /usr/include for headers with overlapping names.
> OK, but then the library should be linked, and that should be ok.

This can only work when libiconv was searched deliberately and not
picked by an accident. GDB from src tools searches for a library for
highlighting code syntax.

>> And in general, is there any reason to want libiconv on NetBSD? Why not
>> to use the libc version one? If there is a missing feature, better to
>> add it in libc, if it is non trivial and libiconv is a stop-gap for
>> something in pkgsrc (I suffer because R picks it.. and stopped
>> installing it recently), it would be good to first fix the the
>> ./ tools scripts.
> Hard to say why.  Often the base versions of things are simple and
> older, in the BSD tradition, and the pkgsrc version might have some new
> features.  Some other package might need that, or some program being
> built outside of pkgsrc.  I don't think you can conclude that anybody
> that wants it is confused.
> So agreed that making sure doesn't have trouble when iconv is
> in pkgsrc sounds good.

Another approach would be to namespace the libiconv header (such as
installing it into $PREFIX/include/libiconv/), so it will be harder to
be picked by an accident.

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index