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

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Reply via email to