Re: converters/libiconv-1.16

[Greg Troxel <gdt%lexort.com@localhost>]

Kamil Rytarowski <n54%gmx.com@localhost> writes:

> ./build.sh 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 ./build.sh tools.

So perhaps build.sh 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 build.sh not to look at them

or

  ban them from pgksrc?

The second seems unreasonable.

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

> 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
> ./build.sh 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 build.sh doesn't have trouble when iconv is
in pkgsrc sounds good.