packaging jack - details on "plan B"

Fri Apr 23 12:29:00 UTC 2010

On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote:
>
>>>  2. Initially release src:jackd2:
>>>     * jackd2 conflicts/replaces/provides jackd
>>>     * libjack0-jackd2 conflicts/replaces libjack0
>>>     * libjack0-jackd2 provides libjack-0.116.0
>>>     * libjack-jackd2-dev conflicts libjack-dev
>>>     * Big fat warning to use -dev package only privately
>>
>>So you propose to introduce 2 virtual packages: jackd and
>>libjack-0.116.0? What problem does introducing the virtual package jackd
>>solve?

ping?

>>>  3. Initially release src:tchack, like jackd2
>>>  4. Update jack-depending packages after testing that it works:
>>>     * Add libjack-0.116.0 as fallback-dependency for libjack0
>>
>>Ah, so at this point you propose to introduce a shlibs file like:
>>
>>,----[proposed shlibs file]
>>| libjack0 0 libjack0 (>= 0.116) | libjack-0.116.0
>>`----
>>
>>is that correct?
>
> Yes, correct.
>
> But an important detail is that I do *not* introduce that virtual
> package to the currently stable jackd1 packaging, only to newly
> introuced jackd2 and tchack packagings!
>
> Only when proven reliable do I want to "infect" the stable package or
> other jack-dependent packages!

As indicated in the other mail, we have two objectives:

 a) switch the default implementation
 b) rearrange packaging to support switching the used implementation

I think b) can and should be done independently on the choice of a),
which means any change to packaging needs to work even if stick with
jack1. Therefore, there is no reason to loose time with planning and
starting the upcoming jackd transition.

> The reason for this is the logic of molding a new Debian releaase: It is
> much easier to rip out newly introduced oddities with not depended on by
> other already-accepted packages, than it is to fix problems involving
> chains of package rebuilds.

You seem to insist on deciding a) before b), while I'd rather see b)
implemented before a), because a) [switching the default implementation]
is technically much easier to implement than b) [packaging changes],
which requires rebuilds of existing packages and therefore takes
potentially a lot of time (build time, coordination with the release
team, etc).

> This also means we do not need to set it all in stone: we do not need to
> discuss *now* what exact wording of each shlib file or naming of virtual
> packages - only if suspected to not work at all is it relevant to
> discuss *now*, else we move faster if discussing and implementing in
> parallel.

I think this is essential for implementing and reviewing the
implementation of step b).

> (I do feel that you suspect the grand plan to not work at all, so do not
> want to stop the current discussion, just want to warn about it
> exploding into all sorts of details not needed to discuss ahead)

You're right, I fear step b) will be technically challenging and I offer
my experience from a similar trick in the FFmpeg packages to review its
implementation.

>>How is the libjack0 package from other implementations supposed to look
>>like? Something like this?
>>
>>Package:   libjack-jackd2-0
>>Provides:  libjack-0.116.0
>>Conflicts: libjack0
>
> Yes, something like that.
>
>
>>>  4. Release jackd1 to experimental, with libjack0 providing   virtual
>>> package libjack-0.116.0
>>>  5. Repackage jackd1 to experimental, with libjack0 providing   virtual
>>> package libjack0-0.116.0
>>
>>what actual changes are involved in this repackaging?
>
> This step is not needed for technical reasons but was included for
> potential political reason: not in the long term emphasize jackd1 as
> being better than the other implementations.

Then let's make all applications to depend on 'libjack0-0.116.0', which
refers to the ABI, and provide a package 'jack-defaults', which builds a
meta-package 'jackd' which depends on the distribution chosen 'default'
jack implementation.

This is similar to the 'gcc-defaults' and 'python-defaults' packages.

> If it truly is irrelevant if a jack-dependent package build against
> jackd1, jackd2 or tchack, then it might (or might not!) make sense to
> stop promoting jackd1 as the most rightous of the implementations.

It depends on the package. Of course there are packages that only work
with a specific libjack implementation. The most prominent example for
this are the respective jack daemon packages. These packages do need a
shlibs.local to override our default libjack shlibs file. This can and
probably will also affect some other jack application packages.

> We could either just abandon the libjack0 and libjack-dev as real
> packages and only rely on virtual package names for build-dependencies
> of common-ABI-conforming projects.

Which is more or less what I propose.

> Or we can create a set of empty meta-packages e.g. libjack-abi-0.116.0
> and libjack-abi-0.116.0-dev, depending on the implementations truly
> obeying the declared ABI - making it possible to ease transition to
> newer ABI if API does not change, even if not all implementations do
> not switch to that newer API at the exact same time (or maybe some of
> them not at all).

I'm not sure if I really understood the practical difference to the
proposal in the paragraph above, other than that the virtual package
'libjack-0.116.0' was renamed to 'libjack-abi-0.116.0'.

As for headers, there is no point in introducing a
'libjack-abi-0.116.0-dev' as there are no binary package depending on
them. Packages that require a specific implementation of jack can adjust
their build dependency accordingly.

> Most likely this step is long after Squeeze.  And quite probably we
> won't do this step at all. Even if completely broken, I do not see
> failure of this step to affect any of the other steps. Is it relevant to
> discuss it in detail now?

Yes, because I think we really can and should implement this for
squeeze!

>> With you're proposal, I think switching from one alternative
>> implementation to another one won't work. For example switching from
>> tschack to jackd3 would break with undeclared file conflicts
>> AFAIUI. And my understanding of this whole hickhack was to allow users
>> to switch jack implementations without having to recompile packages.
>
> If I understand your concern correctly, it is easily handled using
> "Replaces:".
>
> I deliberately did not go into such details, as I can easily imagine
> lots of details being forgotten, but cannot imagine it eventually done
> right.
>
> In other words: Do you only fear that I forgot some details, or do you
> fear that it is impossible to implement at all like I drafted, even with
> carefully composed package relations?

I fear that your proposal would require all jack implementation packages
to be aware of all other "competing" implementation packages. Since we
will definitely  not include each and every potentially competing
implementation (they will exist in 3rd party archives and/or
squeeze-backports), such a requirement will make it impossible to
provide packages that don't suck.

>> (If it works) my idea would allow this; and without having each and
>> every implementation to declare conflicts against every existing other
>> implementation.
>
> Sorry, I lost track: Could you please, in a differently named subthread,
> repeat your proposal?

See <878w8m43r9.fsf at faui44a.informatik.uni-erlangen.de>. After rereading
this mail, it occurs to me that my concern may not be valid at all. I
wrote there:

,----
| Technically, we could play tricks with the shlibs file, I'm doing such
| dirty tricks already in the FFmpeg package, and I think it could work
| with jack as well. For this, we would need to decide which
| implementation is going to provide the headers and library that shall be
| used for application packages at build time. The "trick" would be this:
| 
|  - rename the library package libjack0 to libjack0-jackd1
|  - make 'libjack0-jackd1' provide 'libjack0'
|  - introduce other implementations in the same way, e.g.,
|    libjack0-jackd2 would provide libjack0 as well
|  - install a (common) shlibs file in all implementations to  make
|    application packages refer to libjack0 in their dependencies
|  - pray that we will never need to bump shlibs
| 
| The obvious drawback of this madness is that we cannot use versioned
| dependencies anymore. E.g. newer jack libraries after 0.116.2 introduced
| some new symbols. If some application does not work with an earlier
| version than 0.116.2 of jack, then we cannot express that situation in
| terms of package dependencies anymore. In that case we need to rename
| the name of the virtual package, e.g., libjack0a and recompile the
| world!
| 
| I don't know about the implementation of jackd1 vs. jackd2 or future
| implementation, but my impression of this whole mess makes me feel that
| something like this is not unlikely at all, despite the fact upstream is
| trying really hard to preserve both forward and reverse binary
| compatibility.
`----

Suppose there there is a new ABI synchronization point (let's call it
0.599.0 for the sake of this explanation), which is supposed to be
binary compatible with 0.116.2 and adds additional mandatory features.
In this case we can just make all packages that provide
'libjack-0.559.0' also provide 'libjack-0.116.2'. Packages that have
been compiled against a 0.116.2 ABI can be installed with the new ABI as
well.

For common shared library packages this approach of course doesn't
scale; but usually, they also don't feature different competing
implementations like jack. Moreover, this doesn't seem to occur that
often.

In case the potential 'libjack-0.559.0' was not binary compatible to
'libjack-0.116.2', well, then we'd need an SONAME bump anyway.

So yes, I'm more and more convinced that this should work.

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