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

The Wanderer wanderer at fastmail.fm
Mon Dec 10 13:41:51 UTC 2012


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

> Hi,
> 
> Quoting The Wanderer (2012-12-10 02:25:21)
> 
>> When I attempt to dist-upgrade to current testing, apt wants to remove
>> libjack0 and install libjack-jackd2-0. This is fine; the latter explicitly
>> Provides: the same virtual package as the former, so presumably this is
>> part of an intended package transition.
>> 
>> As part of the same dist-upgrade, apt wants to remove libjack-dev, but does
>> not attempt to install libjack-jackd2-dev. This is not fine.
>> 
>> Please modify package dependencies so that a dist-upgrade on a system where
>> libjack-dev is installed will correctly transition to libjack-jackd2-dev.
> 
> No, because this is not a transition, but two different APIs that (mostly)
> share same ABI.  Which means some packages works fine with either of the JACK
> libraries but some require the jackd2 one - which then pushes the other out,
> including the -dev package.

By "pushes the other out", I infer that you mean "causes the other to become
uninstalled". (At first glance, I would have expected that phrasing to mean
"pushes the other onto the system", i.e. "causes the other to become installed",
which is the opposite of what is actually happening.)

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.

>> Alternately, if this transition would in fact not be correct, please 
>> explain to me what the correct procedure - even if a manual one - would be.
> 
> If you want to develop JACK v1 then avoid installing packages that depend on
> the JACK v2 extensions to the ABI/API.

Actually, what I want to be able to do is to compile programs which use the JACK
libraries. (To me, "develop JACK" would mean "modify the code of JACK itself".)

The bug, IMO, is that the dist-upgrade takes me from a situation where this is
possible (because the appropriate library and its -dev package are installed) to
one where it is not (because although the appropriate library is installed, its
-dev package is not). This can be fixed easily enough by manually installing the
new matching -dev package, but IMO the fact that that package does not get
installed automatically when the older -dev package was already present is a
problem.

The removal of libjack0 and libjack-dev would prevent me from compiling programs
which depend on that API in any case. Assuming it's not possible (or at least
not practical) to arrange for both libraries and their headers to be installed
side-by-side, which your comments seem to indicate is true, this seems
unavoidable.

Continuing to provide the matching -dev package would at least let me continue
to work with programs which *do* know how to work with either API. Admittedly it
would also seem to imply that the APIs provided by the two -dev packages are
compatible, which if not accurate is undesirable, but I'm not sure that that's
worse than the alternative.

> I believe there is no bug here - but am not sure, so please do not give up
> just yet :-)

(Thank you for the attitude; I've had far too many hostile or abrupt responses
to bug reports which the maintainers considered dubious or invalid. It's nice to
get a helpful one instead.)

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

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

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



More information about the pkg-multimedia-maintainers mailing list