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:

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:

gcc "$@"

Certainly, what this architecture independent shell script does is architecture
dependent and thus the package containing it cannot be marked as

I hope this helps.


cheers, josch

Attachment: signature.asc
Description: signature

Reply via email to