[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#357613: debian-policy: Architecture definition contradicts reality



To make a long story short:

The Debian Policy ("arch-os") and reality ("os-arch" for non-Linux
kernel, "arch" for Linux kernel) contradict each other and (at least)
one of them must be fixed.

The facts:

  1. The "dpkg-architecture -L" list of all architectures explicitly
     mentions all non-Linux operating systems and leaves out the "os"
     part in case of Linux. So when there is no OS in the architecture
     specification string, Linux is implied:
        i386
        powerpc
        darwin-i386
        darwin-powerpc
        hurd-i386
        hurd-powerpc

  2. The Debian Policy says that when specifying an architecture
     string somewhere, one "should" use the "arch-os" format.

  3. "dpkg-architecture -i" only understands "os-arch", not "arch-os".
     Short check: "dpkg-architecture -ii386-linux" fails,
                  "dpkg-architecture -ilinux-i386"

  4. The buildd network works with the same architecture list like
     "dpkg-architecture -L", according to Bastian Blank.

To fix the Debian Policy, one would need to change "11.1 Architecture
specification strings" to something like:

    If a program needs to specify an architecture specification string
    in some place, the following format should be used: "os-arch" for
    non-Linux kernels, and "arch" for Linux kernels.

    [60] The following architectures and operating systems are currently
         recognized by dpkg-architecture. The architecture, "arch", is one
         of the following: alpha, arm, hppa, i386, ia64, m68k, mips,
         mipsel, powerpc, s390, sh, sheb, sparc and sparc64. The
         operating system, "os", is left out in case of Linux, or darwin,
         hurd, freebsd, kfreebsd, knetbsd, netbsd and openbsd.

Of course, a few more processor architectures from "dpkg-architecture
-L" would need to be added here as well for completeness' sake.

If one would opt to fix reality, one would have to touch and probably
break a lot of working software, so I would not recommend that based
on the facts known to me.



Reply to: