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