packaging jack...

[Felipe Sateler]

On Mon, Apr 19, 2010 at 09:00, Jonas Smedegaard <jonas at jones.dk> wrote:
> On Sun, Apr 18, 2010 at 09:18:06AM +0200, Reinhard Tartler wrote:
>>
>> On Sat, Apr 17, 2010 at 22:07:56 (CEST), Jonas Smedegaard wrote:
>>
>>> On Sat, Apr 17, 2010 at 09:48:41PM +0200, Reinhard Tartler wrote:
>>>>
>>>> On Sat, Apr 17, 2010 at 21:01:21 (CEST), Jonas Smedegaard wrote:
>>>>
>>>>> On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote:
>>>>>
>>>>>> we (upstream) will make sure they are binary compatible.
>>>>>> all symbols added since jack-0.116 are mandated to be weak.
>>>>>> if there are any issues with binary compatibility these are bugs.
>>>>>
>>>>> Sounds like a promise of a stable API.
>>>>>
>>>>> How about then bumping the API from 0 to 1?
>>>>
>>>> if you mean the SONAME, then you would require rebuilding all
>>>> applications for no reason. There is absolutely no need for this.
>>>
>>> Then packages could depend unversioned on libjack1, instead of versioned
>>> on libjack0 >= 0.116.0.
>>
>> This would be terribly confusing, as it indicates that the SONAME has been
>> bumped which is not the case.
>
> I did not mean that Debian should bump SONAME, but would it not make sense
> for _upstream_ to do so when they claim their library ABI to now be stable?

Because SONAME bumps are for changes.

>>> That would make it possible to offer alternative jackd implementations:
>>>
>>> Alternative implementations simply should not provide a *-dev package, to
>>> enforce build-depending against the "main" jackd implementation (for now
>>> that means jakcd1, might change to a different one in the future).
>>>
>>> I suspect that is the simplest approach to multiple jack implementations
>>> in Debian.
>>
>> The issue with the various flavors of the *-dev package is the least
>> problem here. Moreover, it is neither necessary nor sufficient. Quite the
>> contrary, I think that we need to allow multiple *-dev packages, because
>> some implementation might provide some extra, optional feature that is only
>> declared in an implementation specific header.
>
> Isn't that a contradiction to the upstream claim of library ABI being stable
> since version 0.116.0, or am I missing something?

Strictly speaking, you are correct. However, applications are only
allowed to assume a subset of functions is available. The other
functions cannot be relied upon and applications must test for their
existence at runtime. So, while the exported ABI has not been stable,
the guaranteed ABI has.

But there is a point. If an application is expected to cope with
missing functions at runtime, why not at compile time too?


-- 

Saludos,
Felipe Sateler