Possible JACK ABI changes between 0.118 and 1.9.5

[Felipe Sateler]

On Thu, Apr 8, 2010 at 15:17, Jonas Smedegaard <dr at jones.dk> wrote:
> On Thu, Apr 08, 2010 at 01:24:23PM -0400, Felipe Sateler wrote:
>>
>> On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler <siretart at tauware.de>
>
>>> For jack, I think the amount of symbol files is just too much ATM. First,
>>> I'd strongly suggest to hide the symbols.
>>
>> I agree here. Symbol tracking does not make sense when the signal/noise
>> ratio is too high, as in this case.
>
> I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a
> concern, Reinhard have checked it out and judged it as not worrying, and I
> am satisfied with that.
>
> I do not expect similar noise from here on.  If more noise occur due to
> applied VCS patching, I would want to know, as we then might accidentally
> include upstream API-breaking changes too new for next upstream stable
> release.

The problem is that when the internal implementation changes, you will
get more noise.
As an aside, the symbols file is not to ease tracking of symbol
changes for the maintainer, but for the packaging system.
You need to know *before* applying a patch whether it will take an
update to the symbols file, and why.

>
>
>>>> And yes, if you coding experts (compared to me) consider the symbol
>>>> differences between 1.1.x and 1.9.x not worrying, then I will proceed with
>>>> releasing the current packaging, and postpone polishing the symbol file
>>>> handling till later :-)
>>>
>>> That's really hard to tell with that much noise. That noise also makes
>>> maintaining the symbol files in future unnecessary hard for my taste.
>>
>> Painful, error-prone and superfluous. Shlibs files are enough for the
>> relatively stable jack API, IMO.
>
> We only _assume_ JACK API to be stable - yet we track upstream VCS so should
> not be certain IMO.

Of course we cannot be certain. But our job as package maintainers is
to track that and let the packaging system know, not the other way
around. Before merging from upstream you (as in a generic you, the
person doing the merge) need to know what API and ABI changes it will
contain. And for tracking a relatively stable and noisy library like
jack, a shlibs file is enough. The noisy part is important because the
packaging system (and perhaps the maintainer) might get confused by
the irrelevant symbols.


-- 

Saludos,
Felipe Sateler