On Thu, 2014-12-11 at 02:07 +0100, David Kalnischkies wrote: > Beside from compatibility concerns (old clients might be confused) it is > also wrong from an architectual point of view: A dependency usually is > declared on a package in the same architecture space, so that is the > safest bet. Safe bet maybe (it wasn't in this case), but surely wrong is too a strong word. By definition a package declaring itself to be M-A foreign is saying the arch doesn't matter. It may be a safer bet because of bugs mean the package isn't really the same, but in that case the bug is in the mistaken M-A foreign declaration, not installer thinking M-A foreign doesn't mean what its documentation says. > Other versions of this Debian package from other > architectures might or might not provide the same, but we can't know > that beforehand and we certaintly can't safely assume that for all > versions from this architecture (aka: what would be the result for > packages which change from M-A: none to M-A:foreign or vice versa). True, other versions may not have the same functionality. But we have (always?) had versioned dependencies to cope with that. So if a particular version meets the version preconditions then by definition it meets the API requirements (for some definition of API that includes "command line"). "We certainly can't safely assume for all versions from the architecture" seems wrong to me. Both sides of their dependency have to declare their willingness to accept M-A: foreign. (The depends declares package:any, and the package declares M-A: foreign.) If the version conditions also are fulfilled then surely it is reasonable to assume the maintainers knew what there were doing. As for it going wrong if things change later: if later, either side of the dependency M-A: foreign no longer applies, then they simply remove the declaration. It is never a problem for packages pre-multiarch, because they didn't declare themselves as willing to accept M-A: foreign in the first place. > You might have noticed that I said "provides" in the paragraph above and > that is in fact what is happening here: An M-A:foreign package is > internally mapped as a (versioned) provides, which on one hand is > a giant hack, but on the other hand I am increadibly proud of it as this > helps tremendously in making M-A:foreign "just work" even for old > clients which have never heard of M-A. Yeah, I saw package:any:i386. I recall cleaning my glasses and looking again, and then asking on Debian-mentors what it was I just saw. No one knew. > It puts the candidate version (if any) of the target package as well as > every candidate version (if any) of the packages providing the target > package (if any) in a list and then sorts the list considering various > properties (see CompareProviders here: [0]) to pick the best provider, > which for M-A:foreign packages happens to be the one from the native > architecture, but there are other things to consider as well (which got > added over time. This started very innocently with just priorities…). Here we get the heart of the problem. I presume before multiarch apt_get.Depends.target_pkg target had only one possible package it could point at. Now it potentially has several because there are separate package objects per architecture. You are essentially saying "we should always choose the same architecture as the depends, as that is what we did before". Well that breaks an underlying assumption I made that was true before: some version of target_pkg would be installed. In the example I quoted its not. Effectively that means everything in target_pkg except target_pkg.name is useless in the general case. If pointing it to the right architecture is too hard depreciate it and replace it with target_pkg_name (a string) which express the same thing in an architecture independent way. > Now that it does far more than trivial stuff, I could imagine exporting > this in some way, which this bugreport is actually asking for, but that > needs time for someone to think about a sane API… > any takers (after jessie) ? Again, the sane API to me is expressing is exposing it in apt_pkg.Dependency.target_pkg. If you aren't going to do that then surely apt_pkg.Dependency.smart_target_pkg() would be it - but currently it also returns the wrong architecture in the case I example I gave.
Attachment:
signature.asc
Description: This is a digitally signed message part