Bits from the Release Team: What should go into squeeze?

Felipe Sateler fsateler at gmail.com
Wed Mar 17 18:24:19 UTC 2010


On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard <dr at 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 <dr at 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.

-- 

Saludos,
Felipe Sateler



More information about the pkg-multimedia-maintainers mailing list