libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-25 17:36 GMT+01:00 James Cowgill <jcowgill at debian.org>:
> On 23/11/16 22:44, Jaromír Mikeš wrote:
>> 2016-11-23 23:14 GMT+01:00 James Cowgill <jcowgill at 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