Hi, Quoting David Kalnischkies (2015-04-19 18:52:13) > There is one thing confusing me which I have to highlight through: The > documentation of dpkg mentioned above says that for e.g. Depends "an optional > architecture qualifier can also be appended to the package name […], but the > default is […] the binary package architecture". (the text presents the > derivation from the default for the other forms of relations, so I hope I > haven't created a reductio ad absurdum) > > That sounds for me like > Depends: foo > and > Depends: foo:amd64 > describe the exact same dependency relation as the first one is just > omitting the default value (which is how apt is seeing it). Yet, Guillem > says in the quote and also in the reply to my initial mail that if foo > is M-A: foreign (and we try to install it in i386 flavor), it is > satisfying the first, but not the second as this foo:i386 "does not > really provide :any, it is just able to satisfy unqualified > dependencies." Maybe a good docstring to explain the current interpretation of dpkg would be to say: "For a package bar of architecture amd64, a dependency "foo" is the same as a dependency ``foo | foo:amd64´´" This would mean that the dependency can be satisfied by either the package "foo" in architecture "amd64" or a package "foo" that is m-a:foreign and exists in some other architecture. So maybe the text in deb-control(5) saying "but the default is […]" can be changed to be consistent with dpkg's understanding of such dependency situations? > > What possible situation could there be in which you'd like a m-a:foreign > > package of a specific architecture? If it is a data package containing > > different data per architecture, then it should probably not be > > m-a:foreign. If it's an executable with an arch-independent interface, then > > why would you want to depend on it with an explicit arch? In that case all > > you care about is that you can somehow run the tool (which is a different > > problem). > > As I briefly mentioned earlier, this topic came up in the context of > debug symbols and those traditionally depend on the package they provide > debug symbols for. > > This is a different type of dependency relation. We usually have a > "A needs B" meaning A expects B to provide a certain interface, where > B can decide if it is able to provide this interface irrespective of the > architecture it itself was build for or not (and hence declare itself > M-A:foreign or not and if not can decide if it can at least be > co-installed with its architecture-different siblings with M-A:same). > > But debug symbols A do not care for the interface B provides to the > outside. They care about the inside. A isn't usable to debug a provider > of B, only the real package B can be debugged with it and it can't be of > any architecture, but must be the exact same one (even assuming partial > architectures debug symbols for i486 aren't gone work for i686 in > general even through a i686 system can use a library build for either > i486 or i686 interchangeable) At this point I wonder why debug packages depend on the package they provide debug symbols for. Debug symbols are something that enhances another package, similar to how a plugin enhances another program. I do not see game data packages depend on the engine or documentation depend on the program they document. Why is the dependency even needed? To prevent that users install the package and then it is uselessly lying around the system? I could also now apt-get install libspatialindex4 and it would used by nothing on my system because of course it does not depend on the software that makes use of it. So should instead not the program with debug symbols express a relationship to them? > A slightly weaker version of this might be applications with plugins, where > the application provides an architecture independent interface to the > outside, but a plugin requires an inside connection. Note that an application > might provide this inside connection architecture independent as well. Maybe > it doesn't. And maybe, that changes between versions of the application. Yes, I think debug symbols can be seen similar to being plugins that enhance the functionality of a program. Some plugins like libpam-* do depend on the library they enhance. Others, like libnss-* do not seem to do that. So we are getting the same problems with debug symbols that we have with plugins. Relevant: https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges#Issues > Such applications we mostly dubbed language interpreters so far and invented > M-A: allowed and its companion :any for them to have a way of saying this > could be either way, with a default on M-A:no. > > I wonder if it makes sense to add the inverse companion ':same'¹ to > M-A:foreign, so that you can write "A depends B:same" to ignoring the > fact that B is M-A:foreign much like you would write "A depends B:any" > to highlight the fact that B is "allowed" to be M-A:foreign. > > > That would (in by book) nicely solve the case of debug symbols and other > "inner world" enhancing packages for a M-A:foreign package without using > specific architectures for it (which is harder to write down in metadata > as that is then a dynamic field, rather than statically expressible) > freeing them from the :same meaning they try to emulate in some eyes. Or we just stick to how dpkg handles things right now. The ":same" qualifier would only be meaningful for dependencies on m-a:foreign packages where apt and dose3 currently assume that a m-a:foreign package provides every architecture. But if we accept the way dpkg interprets architecture qualified dependencies on m-a:foreign packages, then ":same" is not needed. So if a way is needed to depend on a specific architecture of a m-a:foreign package, then i rather go with what dpkg currently does than add a new dependency qualifier. > > I want to also take this opportunity to talk about the second point. > > Consider the following situation: > > > > Package: pkga > > Depends: pkgb:any > > Architecture: amd64 > > Version: 1 > > > > Package: pkgb > > Architecture: amd64 > > Version: 1 > > > > If the native architecture is amd64, then currently apt and dpkg will refuse to > > install pkga because the pkgb:any dependency is not satisfied. But why? As the > > dpkg comment above says, pkg:any dependencies are satisfied by a package of a > > *different* arch if the target package is m-a:allowed. The target package is > > not m-a:allowed here but it is also not of a different architecture than pkga. > > So why can neither apt nor dpkg install pkga? > > The spec says: "[…] be satisfied by a package of any architecture, > so long as the python package declares itself as Multi-Arch: allowed". > That is easily read as "if it isn't, then no architecture satisfies it" > even through that isn't explicitly written here. I at least have read it > as such in the past, but now… Yes, I agree that the multiarch spec says that this situation should not be satisfiable. I just think that the spirit of :any is to allow other arches than the native one if the target is m-a:allowed. If the target of the dependency is the native arch then there should not be a problem in the first place. > I agree with you here. I would even go a bit further and declare :any also > satisfiable by an M-A:foreign package of any architecture. This would allow > moving an M-A:allowed package to an M-A:foreign package (or back) without > flagdays or similar. > > I realize through that this obsoletes M-A:allowed (which isn't > necessarily bad) and instead moves us to a world where a package > declares if it should be considered M-A:foreign by default or not and > a package depending on it can override this default with :any, the > potential :same or stick with the default. There's surely is something that would make this not work but I cannot come up with an example. > > > I guess I don't see the problem, either the metadata is wrong or the > > > packages will or will not have satisfiable dependencies. > > > > I guess the problem here is what a specific piece of metadata is supposed to > > *mean*. Only then can we answer the question whether the metadata is wrong. > > Currently, the documentation on this is sparse, resulting in the many > > disagreements between dpkg, apt and dose3 when it comes to multiarch (see my > > other email). > > Indeed. Especially as the documentation which exists tends to contradict > other parts of the puzzle, like MultiArchSpec specifically denying the > existence of foo:<arch>. > > > Wookey already suggested that we finally change that… I think the main > problem with it is that noone knows all parts. While I tend to have an > opinion on how package managers should handle MultiArch on a resolver > level the parts actually happening on the disk, being it dpkg refcount > or simply the <multiarch-triplet> is beyond me (Beside that I am > a total noob in terms of spec/policy writing…). So nobody does the first > step and waits for a non-existing know-it-all master to show up, right? > > > Maybe we, the resolver triumvirate, should just declare ourselves the > ultimate authority in dependency evaluation, take the current > MultiArchSpec as a base and go through the results of Johannes test notice, that the tests I wrote are not exhaustive in that there are some situations they do not test, like two m-a:same packages of the same name self-conflicting with each other or a virtual package they provide/replace. > until we arrive at a spec containing all the things to which we > hopefully can all agree to… How to get that one translated into policy > would remain the topic of another day. That is potentially easier > through if all the major players agree and strictly better than the > status quo. > > > I will be at DebConf and very likely also Camp, but I am not sure its > the right setting. Ideally we would have at least a rough sketch by then > so that the last remaining potentially controversial things can be dealt > with in person (assuming I am not the only one at DebConf/Camp). I'll be at DebConf myself and I hope Guillem and Helmut will too as I feel that they currently have the best understanding of the matter. > Discussing M-A seems to involve a lot of (made-up) examples juggling > qualifications left and right which I don't think is very well suited for > talk. Especially if we talk about ~7700 examples in one session… (oh boy, M-A > has grown fast…) I'll prepare a way to check the results more quickly than going through them one-by-one. Once that is done I can prepare more questions than I already did in the other email I wrote. And then we can maybe have a nice session with a long list of questions that we can discuss during debconf :) cheers, josch
Attachment:
signature.asc
Description: signature