Dear Maintainer,

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

(I suspect that this bug will actually have to be fixed in libjack-jackd2-dev,
but I am reporting it against libjack-dev to make reportbug happy, as that is
the package I currently have installed.)

Hi,

Quoting The Wanderer (2012-12-10 02:25:21)

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.

If you want to develop JACK v1 then avoid installing packages that
depend on the JACK v2 extensions to the ABI/API.


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


Regards,

 - Jonas

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.

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.

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

Quoting The Wanderer (2012-12-10 14:41:51)
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.

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

Not replacement, but alternative.

libjack-dev still exist and should be fully functional.

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.

Is this expected to happen? Does anything strictly depend on jack2?

Maybe we should convert libjack-dev to a dummy package like jackd.

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

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

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.

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.

(Apologies to Felipe for the duplicate reply; I didn't notice until after
sending that the To: didn't include the bug address.)

As part of this same dist-upgrade, a flood of new lib*:i386 packages are being
installed, I think as part of the ia32-libs dummy-package transition. It doesn't
seem impossible that one of them is depending on jackd2 or similar, but I
haven't been able to identify any which does.

Also, if I hold libjack-dev and jackd1, the dist-upgrade no longer attempts to
remove them - but the only packages which disappear from the upgrade or the
new-install lists are libjack-jackd2-0, libjack-jackd2-0:i386, jackd2, and
jackd2-firewire.

My only guess is that one of the new packages Recommends: one of the jack2
packages, but I have no idea which one it might be.

If I understand the problem correctly from what Jonas has explained, that would
not seem like an appropriate solution.

Ah, this hints at a clue. However, I'm not quite sure if I'm correct
or how can we improve it. I'm going to assume ia32-libs-i386 is
attempting an install of version >= 1:0.2.

Normal upgrades (that is, without ia32-libs) shouldn't have a problem.
However, with multiarch we have the following problem:

ia32-libs pulls in ia32-libs-i386, which only exists in arch:i386;
ia32-libs-i386 depends on libjack-jackd2-0 (>= 1.9.5~dfsg-14) |
libjack0 (>= 1:0.118+svn3796-7)

Apt always tries to install the first alternative first, so it tries
to install libjack-jack2-0:i386

libjack-jack2-0 in turn Conflicts with libjack0 (in all archs), which
causes your libjack0:amd64 to be scheduled for removal, whic in turn
causes jackd1 to be removed.

I guess you have jackd installed, which causes apt to try to install
jackd2 (because jackd1 is being removed), which leaves you with a
working jack2 server.

The headers are not installed because nothing causes libjack-jack2-dev
to be installed, and libjack-dev depends on libjack0 (which is no
longer installed).

This is consistent with the above theory.

It could be (but I haven't thought this through). If we:

1. Rename libjack-dev to libjack-jack1-dev.
2. Create a libjack-dev that Depends on libjack-jack1-dev | libjack-jack2-dev

Maybe the upgrade now would now keep the headers installed, since
after libjack-jack1-dev is marked as not installed, apt would try to
install libjack-jack2-dev.

I'm not quite sure the above would really work. Thoughts?

Quoting The Wanderer (2012-12-10 16:30:19)

  jackd2 replaces libjack0 (<= 1.9.5~dfsg-13)
  jackd1 replaces libjack0 (< 1:0.118+svn3796-4)

Even if perhaps in the end both replace same packages of the whole pile
of _updated_ packages, perhaps in the complex puzzle of finding a least
aggressive path to get there the one that replaces most of the _old_
packages as well wins.


Might also be a factor that jackd1 recommends jackd1-firewire which
depends on libjack-jackd2-0 (>= 1.9.5~dfsg-14) | libjack-0.116 - i.e.
vaguely claims to be compatible with jackd2.


Ohhh: Most likely cause is that libjack-jackd2-dev provides libjack-dev!

Why does it do that - it seems plain wrong to me!

Check the meanings with "aptitude --help".

Oh, and if you used apt-get, then don't.  Use aptitude!


 - Jonas

In combination with what Felipe pointed out about ia32-libs and jackd1, that
looks like a plausible reason to me. (The ia32-libs factor also probably means
that part of the culprit is the holds I have in place on a few other packages,
which are also interfering with parts of the ia32-libs dummy-package transition.
As such, this is at least partly my own fault, and may not manifest for
everyone.)

I'd guess that whoever set that up was operating on the same mistaken
assumptions about the relation of the jack implementations to one another as I
was.

On my system, the text output from that command does not include the string
'dist':

wanderer@apologia$ aptitude --help | grep -i dist
wanderer@apologia$

This is with aptitude 0.6.8.2-1.

The aptitude man page does give a hint about what you might be talking about,
but I wouldn't have interpreted the section on the 'full-upgrade' option to mean
what you said. For what little that's worth.

I'd rather not, thanks. I'm told that it's not a good idea to mix-and-match
between aptitude and apt-get, and I find the aptitude UI to be palpably less
friendly and manageable in most circumstances than that of apt-get.

I'm aware that I'm a minority in this, but that doesn't change anything.

(Though now that I look, I see an option in aptitude which I think wasn't there
last time I looked, and which looks quite a bit like something I've been wanting
in apt-get for some time now...)

Quoting The Wanderer (2012-12-10 17:57:18)
held back packages, and (discussed below) you use different tools than
those recommended in release notes for your package handling.

If you (or someone else) can reproduce this issue from a debootstrap of
purely Debian Squeeze packages, then upgraded using an aptitude command,
I will gain iterest in this again.

No (if you mean the assumption of a _transition_ from jackd1 to jackd2
taking place), that is highly unlikely: both JACK implementations are
maintained by same people.

True. Look at the *upgrade commands.

I bet dist-upgrade was deliberately avoided, in favor of those other
more descriptive commands.

Feel free to use an inferior tool.  But note that aptitude is the tool
recommended for upgrading from one release to the next (nowadays, if it
has ever been recommended to use apt-get).

Historically apt-get was a too-simple proof-of-concept tool shipped with
the APT engine. For many years it was broken (treating recommends as
suggests) causing many Debian developers to create broken packages
_because_ apt-get was so very popular.


Regards,

 - Jonas

In case there is confusion, the above is a supported scenario. Of
course,nobody is forced to work on anything they don't want to.

How could this be done? I suspect piuparts could help, but I'm not
particularly knowledgeable about it.

For wheezy the recommended tool is apt-get, see
http://www.debian.org/releases/testing/amd64/release-notes/

Quoting Felipe Sateler (2012-12-10 23:18:34)

I fully agree.  Thanks for clarifying!

Should be possible only with debootstrap or cdebootstrap.

Might need some juggling with "mount --bind ..." for /dev, /proc and
/sys - especially if you want the aptitude fullscreen interface to work.

Simplest networking setup might be to install approx and setup the
chroot to use that: saves setting up name resolving and is benecifial
anyway for many repeated install and upgrade runs.


What I would do is use my pbuilder wrapper scripts
localcowbuilder-create and localcowbuilder-login (which essentially
creates and uses a debootstrap chroot).  If interested, then they are
here:

  git clone git://source.jones.dk/bin
http://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.da.html#upgradingpackages

I am quite happy to learn that apt-get has matured!


 - Jonas

(In hindsight, from what I found in the man page, I should have thought of that
myself.)

wanderer@apologia$ aptitude --help | grep -i upgr
  install      - Install/upgrade packages.
  forbid-version - Forbid aptitude from upgrading to a specific package version.
  update       - Download lists of new/upgradable packages.
  safe-upgrade - Perform a safe upgrade.
  full-upgrade - Perform an upgrade, possibly installing and removing packages.
wanderer@apologia$

That's a reduced and less directly informative version of what's present in the
man page, and again, nothing there seems to imply what you described the purpose
of dist-upgrade (renamed to full-upgrade) to be.

Yes, dist-upgrade can install new packages and remove installed ones; that's
sometimes necessary in order to satisfy changing dependencies, e.g. when a
program adds a new feature which depends on a new library, or when package names
change to reflect new versions. That doesn't say anything about "relaxed
dependency handling" - or, more to the point, "more aggressive solutions" - as I
understand those terms, though.

I meant a minority in the "less friendly and manageable" opinion.

I disagree that apt-get is inferior. It may not provide as broad a feature set
(though I can't swear to that), but IMO as a functional tool it is just as good
or better for most purposes. (Or at least for my purposes.)

I've long been aware that aptitude is by far the more commonly recommended tool
of the two, at least for new users; I've had the impression that that
recommendation extends to all purposes, not just to cross-release upgrades.

As Felipe points out, however, section 4.4 of the wheezy release notes now
explicitly states that apt-get is recommended over aptitude for cross-release
upgrades.


While I'd be interested to continue the discussion of aptitude vs. apt-get, it's
certainly offtopic for this bug. As such, I do not (presently) intend to reply
to any further posts on this bug on that subject, unless they appear to be going
back in the direction of trying to resolve the reported problem.

is legitimate, I'm willing enough at this point to fix my own package-install
situation manually and proceed from there, if no one has any further suggestions
for how to proceed.

Am 11.12.2012 14:44, schrieb The Wanderer:

You could try "aptitude why libjack-jackd2-0" to find out what caused
the installation of that package and thus the removal of libjack0.

  - Fabian

Unfortunately, that just reports
p   libjack-jackd2-dev Provides libjack-dev
p   libjack-jackd2-dev Depends  libjack-jackd2-0 (= 1.9.8~dfsg.4+20120529git007c
                                 dc37-4.1)
which doesn't tell me anything I didn't already know.

I played around with why and why-not for a few other packages as well, but
didn't succeed in tracking anything down. (I wasn't aware of these commands, and
I think they may be useful for future reference.)

It seems possible that this might change if I actually go through with the
"remove libjack0 and libjack-dev" dist-upgrade, so that the jackd2 packages are
actually installed (and the jackd1 packages are not) - but so far I haven't done
that, and I'm not sure I'd like to.

I tried to reproduce this on a clean chroot:

1. Create squeeze chroot
2. Install libjack-dev, jackd and jack1
3. install ia32-libs
4. Add wheezy to sources.list
5. Upgrade apt and dpkg (needed for multiarch)
6. Add i386 foreign architecture in dpkg and apt-get update again
7. apt-get dist-upgrade

This caused a lot of installs (including a :i386 flurry), but
libjack-dev was not removed, and libjack-jack2-0 was not installed.

Well, I have encountered the same problem on a second system (a laptop,
configured similarly although not identically to the original report's desktop
machine), so at least it's not a pure one-off situation.

I don't have any further ideas about how to track down the cause, however, and
although I do have a squeeze-based VM explicitly for testing things related to
Debian I'm not likely to have time to experiment much with this anytime soon.

For the time being, I've gone ahead and dodged around the problem (on one of the
two affected systems) by dist-upgrading with jackd1 and libjack-dev held.
Whether there will be problems with future dist-upgrades I don't know.

FWIW, I've checked the dependencies of every package in that dist-upgrade via
'apt-cache show', and the only references to jack are in the package description
(not the actual dependencies) of vlc-nox. The only packages not modified in
that dist-upgrade which would be modified in one without those two holds are the
four which would be removed and the four which would be installed: jackd1,
jackd1-firewire, libjack-dev, and libjack0 on the one hand, and jackd2,
jackd2-firewire, libjack-jackd2-0, and libjack-jackd2-0:i386 on the other.

If you want to close this as unreproducible or similar, I wouldn't actively
object. It might be worth keeping it open as a low priority just in case
something does get discovered, or for discoverability in case someone else has
the same problem, but I'm not in a position to make that judgment.