Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev

[The Wanderer]

On 12/10/2012 10:08 AM, Jonas Smedegaard wrote:

> Quoting The Wanderer (2012-12-10 14:41:51)
> 
>> Just to clarify: is JACK v2 strictly a superset of JACK v1 in terms of API
>> and presumably ABI? Or are there parts of the JACK v1 API which JACK v2
>> does not provide?
>> 
>> If the former, then I would be inclined to consider this a strict 
>> transition/upgrade situation. If the latter, then I find your comment below
>> about "the JACK v2 extensions to the ABI/API" to be confusing, in that I
>> understand "extensions" to be simply additions on top of what was already
>> present - as opposed to incompatible modifications.
> 
> Ahem, sorry: Please forget about "JACK v2".  That is the wrong name (my 
> fault!) , and confuses matters!
> 
> There are multiple implementations of JACK, and one of those implementations
> happen to have a "2" in its name.

Ah.

In that case (and based on a few other things which I've snipped), the question
becomes why the dist-upgrade is trying to remove libjack0.

libjack-jackd2-0 conflicts with libjack0, and jackd2 depends on
libjack-jackd2-0, so that part is obvious.

I've tried to trace dependencies, but I haven't been able to figure out what is
causing the dist-upgrade to try to install jackd2.

I can prevent dist-upgrade from attempting the removal by holding libjack-dev
and jackd1, but that doesn't explain why the attempt was happening in the first
place. (No other packages get held back as a result of that hold.)

>> At first, I had thought that the -dev package simply hadn't been updated to
>> match the newer library package (and the newer binary packages, jackd2 et
>> al.), so I was waiting for an updated version to appear in testing which
>> would not require me to remove the -dev package in order to dist-upgrade;
>> the thought that it might already have been updated, but simply wasn't
>> being installed as part of the dist-upgrade, didn't even occur to me.
> 
> When you have development tools installed, you will not experience as smooth
> an upgrade as when you do not.

That seems less than entirely desirable, but if that's the design intent of the
package system, then fair enough.

> The purpose of dist-upgrade (as opposed to upgrade) is to relax dependency
> handling to permit more aggressive solutions to the complex puzzle of package
> relation conflicts.

I thought the purpose of dist-upgrade, as opposed to upgrade, was simply to
allow upgrades across scenarios where dependency changes require installation of
different packages rather than simply of new versions of the same packages.

> P.S.
> 
> Skipping parts of your email does not mean that I find it silly or 
> irrelevant, just that I had no comment on it.  We are multiple package 
> developers, and I leave your qustions hanging for others to hopefully 
> contribute too.

Oh, of course; it didn't even occur to me to potentially be offended. I
understand about snipping quite well, even if I don't do it as much as I
possibly should myself.

-- 
    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger