Quoting Thomas Schmitt (2016-09-18 09:09:09)
> Johannes Schauer wrote:
> > [the need for Javascript] should be reported as a bug against the tracker.
> Submitted as
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178
> and subscribed to it.


> > 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.
> How can this script be "Architecture:all" if it does not work as expected
> on some architectures ?
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
> says:
>   "all, which indicates an architecture-independent package."
> So is there a difference between "being architecture independent" and
> "acting architecture independent" ?
> (Hopefully i will never have to decide which of both is in effect.)

When we say "an Architecture:all package is architecture independent" then we
actually mean to say "an Architecture:all package contains content (files)
which are the same across all architectures".

In fact, we could easily live without Architecture:all packages. It would just
mean that mirrors would then carry many identical binary packages for different

So in the debian/control of src:libisofs you could mark libisofs-doc as
Architecture:any and then you would get a libisofs-doc package on each
architecture which would be completely identical (because src:libisofs seems to
build reproducibly [1]). This would totally work as far as dependency
relationships are concerned. It would just "waste" a little bit of mirror space
because now you have to store X identical copies of a binary package, where X
is the number of architectures in Debian.

So the only thing that marking a package as Architecture:all tells you is, that
its *content* is equal across all architectures and that it is thus not
necessary to build and ship an individual copy of that binary package for each


cheers, josch


Attachment: signature.asc
Description: signature

Reply via email to