Sorting the jack build-dependency mess

[Jonas Smedegaard]

On Mon, Oct 25, 2010 at 06:15:49PM +0200, Reinhard Tartler wrote:
>On Mo, Okt 25, 2010 at 17:20:58 (CEST), Adrian Knoth wrote:
>
>> On Mon, Oct 25, 2010 at 04:33:45PM +0200, Reinhard Tartler wrote:
>>
>>> > Unless there's really a need to discuss this in detail, I'd simply 
>>> > upload the new version today.
>>>
>>> so you don't care about unversionable build-depends? this means that 
>>> not a single package in the archive can then do
>>>
>>> Build-Depends: libjack-dev (>> $minimun_version)
>>>
>>> anymore. given that there is a number of jack using packages I'd be 
>>> rather reluctant to do this step.
>>
>> Hmm. Have you seen Jonas' comment? I haven't read it carefully in the 
>> first place, but it seems to make sense now that I read it a second 
>> time:
>>
>>> When versioning is needed, the requirement is either a 
>>> cross-implementation or implementation-specific feature.
>>>
>>> For implementation-specific feature the package should build-depend 
>>> versioned on the specific implementation of JACK.
>>>
>>> For cross-implementation feature we should have all implementations 
>>> provide that new "tag" whenever they mature enough to contain it.
>>>
>>> 4. Make all jack implementations provide: libjack${tag}-dev.
>>>    This is what was done in the past with libjack0.100.0-dev. We 
>>>    need not change anything now, just use a more meaningful tag than 
>>>    "" next time we want to bump.
>>
>> So we now can depend on libjack-dev provided by both, jackd1 and 
>> jackd2. Once there will be something worth to be versioned, we 
>> introduce something like libjack0.119-dev, i.e. for jack session 
>> support.
>>
>> The more I think about it, I could hardly find a reason why a package 
>> wants a specific jackd version at compile time, given that it cannot 
>> rely on this feature to be present at runtime. (please correct me if 
>> you do have such a case)
>
>I really do hope that we don't have such a case, but the typical 
>situation where something like this is required is when you start some 
>kind of transition that requires mass-rebuilds against the updated 
>package. Without versioned dependencies, you need to wait for jack to 
>be compiled *and* installed on each and every arch. The much more 
>robust solution is to add a versioned build-dependency.

This is (as you seem to agree with as well) an ugly trick: it "infects" 
the package with tightened dependency caused only by too limited build 
systems.

Also, I believe that approach is no longer necessary, as it seems we can 
now request arch-specific binNMUs (although I haven't tried it myself, 
just noticed others doing it)


  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20101025/1ced61d9/attachment-0001.pgp>