OpenIndiana Distribution

Some parts of GNU libiconv live under /usr/gnu to avoid collisions with illumos iconv.
Currently the following OI packages depend on GNU libiconv:

pkg:/library/audio/libcdio
pkg:/library/samba/libsmbclient
pkg:/service/network/samba
pkg:/utility/gammu

I don't think that moving all library files to /usr/gnu is a good idea, as this will break existing applications.

I don't think that moving all library files to /usr/gnu is a good idea, as this will break existing applications.

Sorry, that wasn't my question. Not delivering into /usr/gnu/ is what I was asking for.

Why is this package delivering these files into the path /usr/lib and delivering the header+manpages into /usr/gnu/ ?
Doing this in one single package doesn't look right to me.

/usr/gnu/bin/<amd64/|>iconv <<<--- remove gnu/
/usr/gnu/include/* <<<--- remove gnu/
/usr/gnu/share/man/* <<<--- remove gnu/
/usr/lib/amd64/libcharset.so.1.0.0
/usr/lib/amd64/libiconv.so.2.5.1
/usr/lib/amd64/preloadable_libiconv.so
/usr/lib/libcharset.so.1.0.0
/usr/lib/libiconv.so.2.5.1
/usr/lib/preloadable_libiconv.so

So over all, I was asking to not deliver any files into /usr/gnu/ path, instead deliver everything into /usr/<lib|share|bin> - dynmic libaries lib*.so are already there.

There is no illumos iconv in the IPS repository for hipster 2016, right?

The named dependent packages should all load iconv dynamic libraries from /usr/lib, so I'm wondering what the conflict with illumos iconv would be if headers and manpage and binaries are moved to /usr/ without the "gnu/" part?

Regards
Thomas

Short answer: to avoid conflits with illumos iconv - packages system/header, man(3c) pages from system/library vs man(3) pages from library/gnu-libiconv.

So we have new file conflicts introduced by this gnu-iconv package. The former unengaged prefix /usr/gnu is in use since several years by 3rd party packagers on all other Solaris OS except latest OI-Hipster where we now get file conflicts.

New suggestion:

Packages using this gnu-iconv package need special compile-time settings anyways. So it is almost zero effort to not let those packages like samab4 include the header for iconv from /usr/gnu/include, instead, let them include the file from /usr/include/gnu/ or from /usr/gnu/include/gnu/ or any other directory with a name that indicates "This replaces an illumos library by the gnu variant".
The man page files of gnu-iconv can be renamed to have a "gnu-" prefix and stored anwhere.
The package samba4 will need the change "-I/usr/gnu/include" to "-I/usr/include/gnu" or whatever has been chosen as directory.

gnu-iconv package introduced serious file conflicts with the 3rd-party package project. We are approaching FOSDEM conference and end up with Solaris 11 having Libreoffice 4.7 and 5.2, but recent OI-Hipster has none of both. We'll have to tell people to use an older Hipster if they want Libreoffice.

So I can't accept a simple reasoning that gnu-iconv needs go in the way because of file conflicts within illumos iconv itself. It is more that the illumos-ivconv needs to be enhanced to meet the needs as mentioned on IRC e.g. the function iconv_open(“char” | “wchar_t”... )

Please implemment the different storage location for /usr/gnu/include/iconv.h and I'll promise to try compiling a Libreoffice5 package for recent OI-Hipster to be available at the time of FOSDEM (Feb 4th and 5th).

I guess part of the question is to decide whether 3rd party packages should deliver in /usr.

Aurélien Larcher wrote:

I guess part of the question is to decide whether 3rd party packages should deliver in /usr.

No, it is that OI package iconv should not split over /usr and /usr/gnu prefix.
That way, it occupies two directory-namespaces.

Best would be a solution where OI iconv package only delivers files into /usr
or second best:
samba (and potentially other packages) as consumer of OI iconv is changed to use OI builtin iconv functions so OI iconv package is obsolete.

https://github.com/OpenIndiana/oi-userland/pull/3758 - first try on removing GNU libiconv