<kwizart> hi
<kwizart> is it possible to have a sub-package where all binaries and config files are installed so it can became multilib compatible ?
<kwizart> This is for Fedora main repository inclusion...
<bughunter_> hmm... you want to create a binary package?
<bughunter_> what do you mean with "sub-package" ?
* blindvt__ est parti (Read error: 110 (Connection timed out))
* blindvt__ (n=bf@M819P003.adsl.highway.telekom.at) a rejoint #ggi
<kwizart> bughunter, i'm using rpm to package it ...
<kwizart> in this scheme libgii will only contains libraries
<kwizart> -devel rpm sub-pacakge will contain include and library symlink and will requires libgii
<kwizart> (only !)
<kwizart> then all binaries and config files will go to libgii-utils (which will be installed on user choice)
<kwizart> so programs that requires libggi's can uses libraries from both i386 or x86_64 version because that way they could be installed both together...
<kwizart> do you mind i will be wrong with this scheme ?
<kwizart> bughunter, ?
<bughunter_> In the config file, there is a .root entry where GGI searches for the target-libs.
<bughunter_> with rpm you can run a script at install time, which modifies it to your needs.
<bughunter_> that way libs for i386 search for i386 target-libs
<bughunter_> analogous the same for amd64
<kwizart> ok i've saw that but does the config files are needed for programs that link with libgii libraries ? or only used by utils ?
<kwizart> in this case i can move config files to utils sub-packages...
<kwizart> because utils sub-package will be "mono" libs
<bughunter_> the binary libs + config files belong together
<bughunter_> libgii + libgii.conf, libggi + libggi.conf, libggiwmh + libggiwmh.conf, etc.
<kwizart> well, this mean that the package cannot be multilib compatible... then...
<bughunter_> you need to care for this: the libs expect the config files in the path you passed to configure's --prefix option. (default is /usr/local)
<kwizart> config files are in /etc/libggi actually...(this is the sysconfdir value...)
<kwizart> but if a program link to libggi (on x86_64 for sample) it will find the path of libraries in /usr/lib64 (because of some -lgii ?)
<kwizart> then to find other libs it can uses a relative path from the librairies from which it is linked ?
<kwizart> well the other question is do the binaries are necessary for the libs ?
<kwizart> in which case the "solution" could be to have binaries in /usr/lib64/ggi/bin (whith a symlink from /usr/bin )
<kwizart> bughunter, i sorry for all thoses stupid question but having multilibs compatibles package on fedora is mandatory...
<kwizart> what is you feeling about this ?
<bughunter_> when a programs links to -lgii and -lggi, then for x86_64, it has to find the ones in /usr/lib64
<kwizart> indeed...
<bughunter_> the point is: when libgii and libggi want to load the shard target libs, which are in /usr/lib64/ggi for x86_64 and in /usr/lib/ggi for i386
<bughunter_> the actual lib to load has to be looked up in the config file.
<kwizart> ok so can we made it relative: .root: ggi ?
<bughunter_> the program just passes a string "give the x-target" or "do auto-detection"
<bughunter_> all entries in the config file are already relative to the .root entry
<bughunter_> the path to the configfile is hardcoded in libgii and libggi.
<bughunter_> what I try to say is, libgii and libggi must use the correct configfile. the configfile can't be shared multiple architectures.
<kwizart> ok so the libggi's are not multilibs and all package that link with them won't be multilibs also...
<kwizart> do we have a chance that can evolve with nexts version ?
<kwizart> i will try to ask to add libggi's on an exeption list for multilibs until then...
<kwizart> Just a last note I need to remove rpath (which are forbidden in Fedora), it is possible to have a --disable-rpath option at configure step ?
<kwizart> for next release ?
<kwizart> bughunter, i need you advices on theses ^^ ...
<bughunter_> if rpath comes from libtool, then libtool needs to be fixed. configure can't do much in this case.
<kwizart> yes indeed i actually patch libtool... ok then for now libgii is in fedora and libggi will be soon as i expect...