libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-26 13:33 GMT+01:00 James Cowgill <jcowgill at debian.org>:
> On 26/11/16 01:44, Jaromír Mikeš wrote:
>> 2016-11-25 17:36 GMT+01:00 James Cowgill <jcowgill at debian.org>:

>>> All headers in /usr/include/libgig, all references loose the 'libgig/'
>>> and -I/usr/include/libgig is added to the pkg-config file.

Option 3 has been selected by upstream ...

>> 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?
>
> Usually the header location does not change with the soname / ABI. Most
> libraries that do change the header path frequently do it because the
> API changes a lot (eg LLVM).
>
>> Or just /usr/include/gig.h and not allow two versions installed together?
>>
>> your opinion James?
>
> I think one of the 3 options I gave should be used, but I don't mind
> which one. Given that programs seem to be using headers without the
> 'libgig/' prefix already, the middle options seems the least desirable
> but if upstream wants to update all the headers for that option then it can.
>
> As to installing -dev packages together - upstream would also have to
> rename the libgig.so symlink as well as installing headers in a
> different place. I'm not sure it's worth it.

Quoting upstream answer
--------------
However my original suggestion for changing /usr/include/libgig to
/usr/include/libgig4 might still make sense. Since all applications linking
against libgig are calling pkg-config, they would still compile to that new
headers location without any changes to those app's source code or configure
scripts. Do your Debian friends over there have any profound reasons against
this naming scheme (with the lib's major number included)?

But just to make this clear: libgig is also one of the libraries which was and
will change its API frequently becoming incompatible with previous versions.
That's mainly because we decided that preserving backward compatibility for a
long time would mean to much work overhead for us, with probably no relevant
advantage for users in practice.
---------------

James can comment this please?

best regards

mira