packaging jack...

[Reinhard Tartler]

On Wed, Apr 21, 2010 at 09:45:22 (CEST), Jonas Smedegaard wrote:

> On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:
>
>>On Tue, 20 Apr 2010, Jonas Smedegaard wrote:
>>
>>>Let me then adjust and refine my proposal (main point is the same):
>>[snip]
>>>
>>> It was suggested to discuss the introduction of the virtual
>>> libjack-0.116.0 on d-devel.  I consider that unnecessary as it is
>>> coordinated only amongst 3 packages that are all maintained by us.
>>> But if someone finds it relevant and
>>
>> I don't understand the libjack-0.116.0 thing.  Is that going to be the
>> package name?  If so, that sounds like we would be repeating the
>> libjack0.100.0 mistake.
>
> It is more like an add-on tag, indicating the library ABI.

I deduce from this that you don't want to adjust the shlibs file of
libjack package to make application package generate dependencies on
libjack-0.116.0 then?

If that's correct, then I didn't understand the purpose of the virtual
package name at all. My (and torben's idea AFAIU him) was to make
application packages generate dependencies on the virtual package that
indicates the promised 'stable ABI' by default, unless the package has
specific requirements on some (extended) libjack implementation. The
most prominent example of this are of course the respective jackd
implementations. In those cases, a shlibs.local overrides the default
shlibs.

> Each implementation will have their own package names, and then in
> addition they will all claim to provide a _virtual_ package name called
> "libjack0.100.0".  So not like earlier (which was before I got involved
> in the team, so I only know of the result, not the considerations behind
> it).

I wasn't involved at that time either, but I guess this was done because
at that time both the ABI and API was not stable (enough or at all).

> If upstream had a more strict coding style (and if I understand it
> correctly, I am a scripter myself, not a coder, so looking at it from
> aside), then they would probably instead have bumped the SONAME and we
> would not use an odd version like this but just use "libjack1" as the
> tag name.

No they wouldn't. They already track ABI very strictly which is the best
that could happen to a packager. AFAIUI, upstream is handling binary
compatibility in the best way given the circumstances.

The issue that makes the matter complicated are the different
implementations that are required (or at least supposed) to implement an
binary interface. This is packaging wise pretty unusual; versioned
provides would make things here much easier.

> We could also use "libjack-2010" or "jack-lib-new-generation" if those
> better indicate what is common across the implementations.  Do upstream
> perhaps have an internal codename for the unification/freeze that we
> could reuse?

They refer to the "binary interface as expressed by libjack version
0.116". For this reason, we invent the virtual package libjack-0.116 to
express "we promise that each and every package that provides this
package name is actually binary compatible to the libjack library
version 0.116". (that's BTW the main reason why I think we need to
adjust the shlibs file and mass rebuild each and every package that
build-depends on libjack-dev).

>>> Later it might make sense to try support officially linking against
>>> alternate implementations. If that works out, it might make sense to
>>> repackage jackd1 similar to the others, so as to treat all
>>> implementations as equal competitors.  But that is post Squeeze IMO.
>>
>> An alternative to keep from holding up squeeze could be: keep things
>> as they are currently... with Jack 1.  Keep Jack 2 in sid (or
>> something) so users can upgrade to it if they want.  Meanwhile, the
>> proposal sounds odd because of the way that the package names relate
>> and the 0.116.0 thing.
>
> This is contained in my proposal: Just tag the newly added
> implementations with a dummy release-critical bugreport to keep them
> from trickling into testing and from there to stable, and you have
> "things as they are currently".
>
> What I propose goes _beyond_ that, though.  It is a no-brainer to revert
> our git to status quo, but what then?  I did not put timestamps on each
> step but it _is_ an ordered list, and if some step fail or gets stalled,
> then the affected packages will not reach Squeeze in time for the
> release.  In other words, if something (or someone - e.g. ftpmaster)
> turns out to not work right, then what will for sure stay in the archive
> and get shipped with Squeeze be jackd1.

TBH, I don't understand how your approach is addressing the challenge:
"Enable users to choose their jack implementation" in a way that works.

I guess I need to find a counter example to show how things break.

>> Right now going from jack1->jack2 is a clean upgrade because of the
>> version numbers... so (for me) that would be fine. This all hit the
>> fan because it's hard for users to go from jack2->jack1 because they
>> have to force a downgrade.... and the LAD list was told that squeeze
>> would ship with Jack 2.
>
> Indeed.  My proposal puts first priority on keeping what we know is
> stable (and what turns out to not be abandoned upstream after all), and
> it puts second a way to try switch not only from one implementation to
> one other (that's easy) but from a single implementation to a choice of
> multiple ones.  Not multiple ones installed concurrently, but multiple
> mutually conflicting ones available for installation concurrently.

So to put straight: you propose to not switch to jackd2 at all but stick
with jackd1? I guess you are aware that adi has negotiated with opensuse
to do a coordinated switch to jackd2, and is currently trying to agree
on something similar with fedora? I think that stepping back from this
plan would makes us look, well, strange.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4