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 doBuild-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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
