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

[Jonas Smedegaard]

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.

Maybe in the future we will look back and realize than jackd2 became the 
"surviver" of those currently in friendly competition, but there is no 
transition going on currently.

I repeat: it is not a transition.

There is a common ABI, shared among multiple implementations, and there 
is development headers which conflict with each other, and there is 
linkage depending not on the shared ABI but on unique features of one of 
them.


> To be clear, I'm not saying there's a functionality problem here. The 
> problem I see is one of user-friendliness and discoverability.

You might be right that there is a more elegant way to express the 
complex situation with these package relations - but first step in 
helping with that is to understand what are the package relations we try 
to express ;-)


> It took me several days and a chance comment from someone on 
> debian-user to figure out that there even *was* a replacement -dev 
> package.

Not replacement, but alternative.

libjack-dev still exist and should be fully functional.


> 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.

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.


 - Jonas

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.

-- 
 * 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: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20121210/74848c6d/attachment.pgp>