Hi, Quoting Thomas Schmitt (2016-09-17 17:51:16) > I saw the mouseover text "Toggle details", but the click only brought me to > https://tracker.debian.org/pkg/libisofs# > because i have Javascript disabled. that should be reported as a bug against the tracker. Without Javascript, the default should be to see the expanded view or otherwise the data will be invisible for users without Javascript. It should be simple to make it such that users with javascript see the collapsed view by default and have to click to expand it. Though since I also didn't see the drop-down "button" myself at first maybe this UI element of the tracker needs some rethinking anyways. > Is there a diagram or table which relates Architecture: and Multi-arch: ? I don't see how this should be done. The fields are not related except that they both have the character sequence "arch" in them. The Architecture field tells you whether the binary package is architecture specific or not and if it is architecture specific to which architecture it belongs. Architecture:all means that the data inside the package doesn't differ between different architectures. Hence, Architecture:all packages are only built once by buildds and can then be used on any other architecture where their dependencies are satisfied, even before there was multiarch. For all other values of the Architecture field, the binary package is architecture specific and before there was multiarch you only were able to install a package that was of Architecture:foo on a system with native architecture foo. You can find out your system's native architecture via $(dpkg --print-architecture). With multiarch it is now also potentially possible to install a package of architecture bar on a system with native architecture foo. A short summary: If a package is Multi-Arch:same then it is potentially possible to install a package with same name and version but different architecture at the same time. If a package is Multi-Arch:foreign, then a package of architecture foo is potentially able to satisfy a dependency of a package with architecture bar. > Coming back to the diagram question: Doesn't "Architecture: all" imply > "Multi-arch: foreign" ? No. Multi-arch:foreign means that a package of architecture foo is able to satisfy the dependencies of a package with architecture bar. This means that the functionality and interface that your Architecture:all package provides must be independent of the native architecture (Architecture:all packages are currently treated as if they were of the native architecture). While this is certainly the case for many Architecture:all packages, there also exist many for which it is not the case. Here an example: Imagine your Architecture:all package was just a shell script which provided the functionality of printing "hello world" on standard output: #!/bin/sh echo "hello world" The package that just contains this script could probably be marked as Multi-Arch:foreign as the functionality it provides is architecture independent. No matter the architecture of the package depending on it, they would get the requested functionality: the string "hello world". But now imagine an Architecture:all package doing this: #!/bin/sh gcc "$@" Certainly, what this architecture independent shell script does is architecture dependent and thus the package containing it cannot be marked as Multi-Arch:foreign. I hope this helps. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature