On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard <d...@jones.dk> wrote:
> On Wed, Mar 17, 2010 at 01:29:31PM -0400, Eric Dantan Rzewnicki wrote:
>> On Wed, Mar 17, 2010 at 06:24:10PM +0100, Jonas Smedegaard wrote:
>>> On Wed, Mar 17, 2010 at 02:09:33PM -0300, Felipe Sateler wrote:
>>>> On Wed, Mar 17, 2010 at 13:50, Jonas Smedegaard <d...@jones.dk> wrote:
>>>>> On Wed, Mar 17, 2010 at 01:23:03PM -0300, Felipe Sateler wrote:
>>>>>> Also, if my understanding is correct, jack2 is ABI compatible with
>>>>>> jack1, so no library transition is needed.
>>>>> That was my impression too.  If so, why don't we ship *both*?
>>>>> Let's rename jackd → jackd1, package jackd2, and let both binary
>>>>> packages provide jackd as a virtual package.
>>>> There are a bunch of packages depending on jackd (>= something), so
>>>> this approach would break those apps.
>>> Ah, good point.
>>>> A metapackage depending on jackd1 | jackd2 would work, though.
>>> I find a metapackage an inelegant approach.
>>> My suggestion is then to keep jackd as-is for now but
>>>  a) introduce a new jackd2
>>>     (hopefully ready for inclusion with Squeeze),
>> It is already in experimental (as jackd 1.9.4+svn3842-2).
> The code, yes.  But with source package name identical to older code so
> cannot coexist with older jackd in same distribution release.
> What I propose is to ship the new code as a separate source package and a
> separate binary package.  The binary package will conflict with the similar
> binary package provided by the older code (at least at first), and probably
> no binary library packages will be provided either.
> My proposal is to package jackd2 _distributable_ in parallel to existing
> stable jackd1 but not _installable_ in parallel.

There is a problem, though. The library names collide, so one would
have to have libjack1-0 and libjack2-0. This would mean that the
shlibs files would have to provide alternative dependencies (like
ffmpeg is doing for the unstripped variants), which would require a
binNMU run to change the dependencies, and finally then jack2 could be
uploaded. Oh and take steps to make sure jackd1 depends on libjack1-0
only (and same for jack2). I think this is much too complicated.


Felipe Sateler

pkg-multimedia-maintainers mailing list

Reply via email to