Bug #7755

library/gnu-libiconv should not deliver files to /usr/gnu/ prefix

Added by Th. Wagner over 4 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


library/gnu-libiconv delivers files to /usr/gnu/ prefix which leads to occupying two directory-namespaces.
Librariey files go to /usr/lib but binary executalbs and manpages go to /usr/gnu/ prefix, this is not consitent.

These files should be moved to /usr prefix: (remove "gnu/" from libiconv.p5m)

Once this change is implemented and available, the SFE variant of libiconv can live propperly in /usr/gnu/ prefix and this enables Libreoffice installs.


Updated by Alexander Pyhalov over 4 years ago

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


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


Updated by Th. Wagner over 4 years ago

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/

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?



Updated by Alexander Pyhalov about 4 years ago

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.


Updated by Th. Wagner about 4 years ago

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


Updated by Aurélien Larcher almost 4 years ago

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


Updated by Th. Wagner almost 4 years ago

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.


Updated by Alexander Pyhalov over 3 years ago - first try on removing GNU libiconv


Updated by Alexander Pyhalov over 3 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF