[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#832503: apt: foo:any dependency is not handled correctly when foo is not Multi-Arch: allowed

Control: reassign -1 dpkg 1.18.9

On Tue, Jul 26, 2016 at 10:29:21AM +0200, Raphaël Hertzog wrote:
> I have a package dependency "firefox-esr:any | firefox:any | www-browser" in a
> metapackage. Unfortunately firefox-esr is neither "Multi-Arch: foreign" nor
> "Multi-Arch: allowed" (I filed #832501 to request this) and when I try to
> install this meta-package it will not install firefox-esr at all, instead
> it will pick a random web browser (thus considering www-browser and not
> firefox-esr:any).
> Given the lack of "Multi-Arch: allowed", it is expected that a foreign
> firefox-esr cannot fulfill the dependency.
> But firefox-esr:native should fulfill the "firefox-esr:any" dependency
> and apt should install this package in response to the metapackage
> installation request.
> Discussing this on IRC lead to this:
> 09:56 <DonKult> again: a dependency "foo:any" can be satisfied by a package foo
> only in two ways: a) foo is M-A: allowed. b) foo explicitly "Provides:
> foo:any".
> 09:57 <buxy> DonKult: let's fix the spec?
> 10:01 <DonKult> you can find mails from me discussing different interpretations
> for some things, but the discussion ended at DC15 with an agreement on the
> interpretation as implemented by dpkg. I am not going to breach contracts.

As much as I am surprised to see me quoted from IRC directly (especially
in ways which could be misinterpreted), now that it stands here for
eternity I feel obligated to clarify:

The whole discussion (which this is a short excerpt from) and especially
that sentence was meant to highlight that I am neither the Multi-Arch
god changing the spec as I see fit nor that there is incredibly much
point in APT changing first – if anything dpkg should change first as
having them disagree on things is always bad, but having APT be more
accepting than dpkg is horrible… (others needing to change include dose,
britney, bootstrap, …).  The bug hence belongs over there: reassigning.
It is arguably also the place where more multiarch people hang out.

I mentioned DC15 specifically as Provides were covered there which
specifically ruled out "foo:amd64 depends www-browser" to be satisfied
by "bar:i386 provides www-browser", so the most reasonable course of
action seems to be a "foo:amd64 depends www-browser | www-browser:any"
and "bar:i386 provides www-browser, www-browser:any" at the moment.

> If the Multi-Arch specification says otherwise, then we should
> probably consider improving it to allow this case. Are you aware of
> cases where allowing this would break something?

> Given that the Multi-Arch annotation is not under the control of the package
> specifying the dependency it would seem better to have a sane and tolerant
> fallback when the target package has no Multi-Arch annotation instead of
> refusing to satisfy the dependency even when when we have a native package
> which is installable.

I think it would be more sensible to allow a native foo to always
satisfy foo:any, regardless of the M-A state of foo. After all,
installing the native foo is the preferred course of action for foo:any
anyhow and its M-A state is ignored if only it provides foo:any.

You could further argue that a M-A:foreign foo should have all foo's
satisfy foo:any as they are treated as equivalent to the native foo in
other cases, which would eliminate the need for "foo | foo:any" entirely
as "foo:any" would provide (SCNR) the functionality of:
a) the native package foo,
b) a native package providing foo,
c) a foreign package foo,
d) a foreign package providing foo or
e) any package providing foo:any

Still not what ':any' means intuitively, but at least close and avoids
the problems of any would it really mean any.

If on the other hand the gain (elimination of the or-group, perhaps
simpler transitions between states) is worth the pain (implementing it
everywhere) is a question I don't have an opinion on.

My strongest opinion really is that the APT mailinglist/bugtracker isn't
the place to discuss this – nor is my existance exorbitantly interested in
'chairing' such a discussion at the moment as there are other things
I should be working on, which is also why I only think in private that
this might be a topic which should end up on d-d@ as it effects at least
the big virtual packages.

Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature

Reply to: