Is this architecture related to other architectures already in the archive,
-or that also should be considered, either now or in the future? Can the related
-architectures be supported in a single architecture (eg, with a biarch arrangement)?
-
Are there 3 or more developers (or n-ms) actively maintaining the port? Who are they?
-
What sort of architecture is this? Desktop/workstation? Mainframe/supercomputer? Embedded? Something else?
-
Does it have any users? If a desktop system, are there Debian admins who
-run Debian systems on the arch? If an embedded system are there real systems
-shipping that a Debian port will be useful for? If a mainframe system are there
-real systems with many users that a Debian port will be useful for? Who are they?
-
Is there kernel and toolchain support? At what level? Are the latest versions supported, or are
-legacy releases required for compatability with some hardware?
-
Has the ABI stabalised, or are there major ABI changes coming
-up? Is the ABI stable enough to ensure users will be able just "apt-get
-dist-upgrade" from one version to the next?
-
How do you install a system? (URL to a HOWTO)
-
Has a buildd been setup? How much of the archive has been built (count by
-source package, builds of old versions are fine for this case)?
-
What hardware is potentially available as a fast buildd?
-
Is there any corporate support of this arch, and the Debian port in particular?
-
Is there an example box developers can login to to see if it works?
-
-
-
It's also worth considering whether the port has any special
-requirements. If the port is mainly for embedded systems, it may be
-appropriate to have different installation or release arrangements
-compared to normal desktop/workstation architectures.
-
-
Further requirements for OSes
-
-
Examples: hurd, opensolaris, kfreebsd
-
-
-
Are there existing comprehensive free distributions of this OS? If
-so, why is a Debian distribution useful?
-
What demonstrable benefits does this OS have over existing Debian OSes?
-
Does this system have a standard Unix API?
-
Does the OS support modern glibc and gcc?
-
What is the license on the kernel and libraries? Is it free? Is it GPL
-compatible? (Note that if it's not free, building software for it violates the
-Social Contract; and if it's not GPL compatible, GPL software such as dpkg can't be
-linked to it)
-
Does the OS build largely without source changes? If so, what proportion of
-the archive has built?
-
-
-
It's worth thinking about whether it makes sense to integrate the
-port with Debian's Linux-based distribution -- having separate sources
-may not only reduce the impact on the release architectures, but also
-make it easier to do development on the new OS as well.
-
-
Note that if significant changes are needed to more than just a small
-number of packages, your porting team will not only need to provide
-patches for most of those changes and make sure they work, but also
-ensure they don't cause problems for existing ports.
-
-
-
+
+
+
amd64, armel, alpha, m68k. Basically everything that uses
+ the Linux kernel.
+
+
+
OS
+
hurd, opensolaris, kfreebsd. Ports that do not use the
+ Linux kernel, but their own.
+
+
+
+
+
+ A new architecture has to follow the Rules for new architectures,
+ and answer all Questions for new architectures.
+
+
+ A new OS has to follow the Rules for new architectures and
+ answer all Questions for new architectures as well as all
+ Further questions for OSes.
+
If an architecture fails to be included in 2 successive
+ official releases, it is moved out of the official archive (and
+ away from the ftp-master.debian.org host).
+
+
If a removed architecture later can prove it will be able to
+ make the next official release, it can be re-included into the
+ official archive. This step additionally needs the acceptance of
+ the Security, the Release and the Debian Admin Team. (It needs
+ security autobuilders, porter machines, etc.)
+
+
+
Rules for new architectures
+
+
A newly included architecture has to be completely built using
+ packages available in plain Debian sources. External patches cannot
+ be used.
+
+
At the time of inclusion a minimal set of binary packages will be
+ imported into the archive, just enough to get build-essential ready to
+ go and an official buildd setup and running. Everything else will be
+ rebuilt from scratch. As soon as enough is rebuilt to get the initial
+ toolchain built using "native" Debian, this will be rebuilt too.
+
+
The packages imported from external source and used for the initial
+ build run must be signed by one of the lead porters, who must be a DD.
+
+
There must be at least two machines ready to be maintained
+ by the Debian System Administrators, so at the start of its
+ lifetime there will be at least one buildd and one porter machine.
+
+ The inclusion into the archive will almost certainly happen before
+ the machines are handed over to DSA, but this should happen as
+ soon as feasible afterwards.
+
+ (Note that this is the minimum to get into the archive. The release team
+ may have additional requirements to allow the architecture to release, so
+ there would normally need to be more machines, especially more
+ buildds.)
+
+ Note: The machines, their setup and hosting etc should be
+ coordinated with DSA and needs to be acceptable to DSA. Please
+ coordinate with
+ them, they might be able to help you in more ways
+ you can imagine, but at least they can help to avoid useless work
+ if a hosting wouldnt be acceptable. :)
+
+
+
+
Questions for new architectures
+
+
+
Are machines available to buy for the general public?
+
Is full source available?
+
Is this architecture related to other architectures already in
+ the archive, or that also should be considered, either now or in
+ the future? Can the related architectures be supported in a single
+ architecture (eg, with a biarch arrangement)?
+
Are there 3 or more developers (or NMs) actively maintaining
+ the port? Who are they?
+
What sort of architecture is this? Desktop/workstation?
+ Mainframe/supercomputer? Embedded? Something else?
+
Does it have any users? If a desktop system, are there Debian
+ admins who run Debian systems on the arch? If an embedded system
+ are there real systems shipping that a Debian port will be useful
+ for? If a mainframe system are there real systems with many users
+ that a Debian port will be useful for? Who are they?
+
Is there kernel and toolchain support? At what level? Are the
+ latest versions supported, or are legacy releases required for
+ compatability with some hardware?
+
Has the ABI stabalised, or are there major ABI changes coming
+ up? Is the ABI stable enough to ensure users will be able just
+ "apt-get dist-upgrade" from one version to the next?
+
How do you install a system? (URL to a HOWTO)
+
Has a buildd been setup? How much of the archive has been
+ built (count by source package, builds of old versions are fine
+ for this case)?
+
What hardware is potentially available as a fast buildd?
+
Is there an example box developers can login to to see if it
+ works?
+
+
+
It's also worth considering whether the port has any special
+ requirements. If the port is mainly for embedded systems, it may be
+ appropriate to have different installation or release arrangements
+ compared to normal desktop/workstation architectures.
+
+
Further questions for OSes
+
+
+
Are there existing comprehensive free distributions of this OS? If
+ so, why is a Debian distribution useful?
+
What demonstrable benefits does this OS have over existing
+ Debian OSes?
+
Does this system have a standard Unix API?
+
Does the OS support modern glibc and gcc?
+
What is the license on the kernel and core libraries? Is the license
+ free? Is the license GPL compatible? (Note that if it's not free, distributing
+ the software violates the Social Contract; and if it's not GPL compatible,
+ GPL software such as dpkg can't be linked to it)
+
Does the OS build largely without source changes? If so, what proportion of
+ the archive has built?
+
+
+
It's worth thinking about whether it makes sense to integrate the
+ port with Debian's Linux-based distribution -- having separate sources
+ may not only reduce the impact on the release architectures, but also
+ make it easier to do development on the new OS as well.
+
+
Note that if significant changes are needed to more than just a small
+ number of packages, your porting team will not only need to provide
+ patches for most of those changes and make sure they work, but also
+ ensure they don't cause problems for existing ports.