2016-11-25 17:36 GMT+01:00 James Cowgill <jcowg...@debian.org>: > On 23/11/16 22:44, Jaromír Mikeš wrote: >> 2016-11-23 23:14 GMT+01:00 James Cowgill <jcowg...@debian.org>: >>> On 23/11/16 22:02, Jaromír Mikeš wrote: >>>> Ok ... fixed now :) libgig builds fine ... >>>> I also tried build qsampler ... it builds but will need some patch to >>>> fix search for libgig/SF.h ... quite should be easy >>> >>> If qsampler needs a patch, you've done something wrong. Moving the >>> libraries should have had no affect on other packages (unless they are >>> actually hard coding the lib path). Why have the headers changed? >> >> qsampler search for libgig/SF.h ... till now (with old libgig) it was >> never found ( it wasn't exist) and qsampler was build without this >> fuctionality >> SF.h is new header provided by new libgig 4.0.0 ... and now all header >> are moved from usr/include/libgig to usr/include/ >> >> You still think I have done something wrong? > > OK I've had another look and I think I understand the confusion here: > upstream have decided to move the headers from /usr/include to > /usr/include/libgig without adjusting anything else to cope with that. > > Your method would work here, but I think you should ask upstream what > they want here since changing it later is a PITA. The options are: > > All headers in /usr/include, all references to them loose the 'libgig/' > prefix. > > All headers in /usr/include/libgig, all references must have a 'libgig/' > prefix (including the headers themselves). > > All headers in /usr/include/libgig, all references loose the 'libgig/' > and -I/usr/include/libgig is added to the pkg-config file.
Answer somehow came from upstream itself before posting to him ... as he reviewed my patch 05-fix-include-dir.patch > as far as I remember the previous Debian maintainer of libgig, I think he said > the header files should be bundled in a subdirectory according to Debian > policies, and the the subdirectory name should reflect the library version > (i.e. /usr/include/libgig4/gig.h, etc.). The motivation was to be able to > install i.e. two different versions of the same library (i.e. in this case > i.e. libgig3-dev, libgig4-dev) which would otherwise cause a file conflict. > But obviously I am not up to date regarding latest Debian policies. What would be best from debian point of view? /usr/include/libgig4/gig.h or /usr/include/libgig7/gig.h to reflect rather soname than release? Or just /usr/include/gig.h and not allow two versions installed together? your opinion James? best regards mira _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers