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

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to