[med-svn] [Git][med-team/policy][master] 2 commits: first draft of architecture policy
Michael R. Crusoe (@crusoe)
gitlab at salsa.debian.org
Sun Apr 21 14:35:18 BST 2024
Michael R. Crusoe pushed to branch master at Debian Med / policy
Commits:
18f82396 by Michael R. Crusoe at 2024-04-21T13:35:09+00:00
first draft of architecture policy
- - - - -
4179a7ac by Michael R. Crusoe at 2024-04-21T13:35:10+00:00
Merge branch 'arch-proposal' into 'master'
first draft of architecture policy
See merge request med-team/policy!3
- - - - -
2 changed files:
- policy.html
- policy.rst
Changes:
=====================================
policy.html
=====================================
@@ -445,12 +445,13 @@ ul.auto-toc {
</li>
</ul>
</li>
+<li><a class="reference internal" href="#handling-non-trivial-issues-on-less-popular-architectures" id="toc-entry-63">Handling non-trivial issues on less-popular architectures</a></li>
</ul>
</li>
-<li><a class="reference internal" href="#embedding-large-test-data" id="toc-entry-63">Embedding Large Test Data</a></li>
-<li><a class="reference internal" href="#faq" id="toc-entry-64">FAQ</a><ul>
-<li><a class="reference internal" href="#how-to-easily-help-upstream-exactly-reproduce-build-test-errors-that-may-be-specific-to-debian" id="toc-entry-65">How to easily help upstream exactly reproduce build/test errors that may be specific to Debian?</a></li>
-<li><a class="reference internal" href="#what-to-do-if-a-large-package-does-not-build-on-a-specific-autobuilder-architecture" id="toc-entry-66">What to do if a large package does not build on a specific autobuilder architecture?</a></li>
+<li><a class="reference internal" href="#embedding-large-test-data" id="toc-entry-64">Embedding Large Test Data</a></li>
+<li><a class="reference internal" href="#faq" id="toc-entry-65">FAQ</a><ul>
+<li><a class="reference internal" href="#how-to-easily-help-upstream-exactly-reproduce-build-test-errors-that-may-be-specific-to-debian" id="toc-entry-66">How to easily help upstream exactly reproduce build/test errors that may be specific to Debian?</a></li>
+<li><a class="reference internal" href="#what-to-do-if-a-large-package-does-not-build-on-a-specific-autobuilder-architecture" id="toc-entry-67">What to do if a large package does not build on a specific autobuilder architecture?</a></li>
</ul>
</li>
</ul>
@@ -994,6 +995,12 @@ answer to the bug reports. For more occasional works, you can do a
<a class="reference external" href="https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-team-upload">team
upload</a>.</p>
</li>
+<li><p class="first"><strong>Build-Depends.</strong></p>
+<p>For new packages of tools that produce architecture-dependant binary packages
+(anything besides <tt class="docutils literal">Architecture: all</tt>), then the following dependencies
+SHOULD be listed to skip building on non-64-bit and non-little-endian
+architectures: <tt class="docutils literal"><span class="pre">architecture-is-64-bit,</span> <span class="pre">architecture-is-little-endian</span></tt>.</p>
+</li>
<li><p class="first"><strong>Standards-Version.</strong></p>
<p>Please always use the latest unless there are concerns for
backporting. If no changes are needed, please indicate this fact in
@@ -1018,6 +1025,9 @@ testsuite can be executed via the <tt class="docutils literal"><span class="pre"
autopkgtest package or the <tt class="docutils literal">sadt</tt> command from the devscripts
package.</p>
</li>
+<li><p class="first"><strong>Rules-Requires-Root.</strong></p>
+<p>Should be <tt class="docutils literal">no</tt>, if possible.</p>
+</li>
</ol>
<p>It is a very good idea to use <tt class="docutils literal"><span class="pre">Config::Model</span></tt> to unify the formatting
of <tt class="docutils literal">debian/control</tt>. To do so make sure you have installed</p>
@@ -1334,9 +1344,31 @@ the Debian Wiki.</p>
</div>
</div>
</div>
+<div class="section" id="handling-non-trivial-issues-on-less-popular-architectures">
+<h2><a class="toc-backref" href="#toc-entry-63">Handling non-trivial issues on less-popular architectures</a></h2>
+<p>Given that Debian-Med is targeting the use cases of "medical practice and
+research" and medical institutions and researchers are almost entirely running
+on <tt class="docutils literal">amd64</tt> and <tt class="docutils literal">arm64</tt> systems as of 2024, and that there is no tradition
+of big-endian computing in the biomedical and life sciences, then we choose to
+allow ourselves to restrict the architectures where scientific tools and
+applications packaged by the Debian-Med team are built.</p>
+<p>If any package maintained by the Debian-Med team has a non-trivial isssue on
+architectures that are unlikely to be needed by our users, then removal of the
+binary packages from those architectures SHOULD happen, subject to the following:</p>
+<ol class="arabic simple">
+<li>If any of the binary packages of the targeted source package are
+reverse-dependencies of non-Debian-Med team packages (even indirectly), then
+such a removal must be coordinated and approved by the other teams or
+individual maintainers.</li>
+<li>Avoiding building on the problematic architectures by adding a
+build-dependency on <tt class="docutils literal"><span class="pre">architecture-is-64-bit</span></tt> and/or
+<tt class="docutils literal"><span class="pre">architecture-is-little-endian</span></tt> SHOULD be done instead of restricting the
+<tt class="docutils literal">Architecture</tt> list, if that isn't too overbroad.</li>
+</ol>
+</div>
</div>
<div class="section" id="embedding-large-test-data">
-<h1><a class="toc-backref" href="#toc-entry-63">Embedding Large Test Data</a></h1>
+<h1><a class="toc-backref" href="#toc-entry-64">Embedding Large Test Data</a></h1>
<p>Often a lot of times, there's a need to fetch external data for adding autopkgtests.
We choose to make a separate orig tarball for data if the size of data far exceeds the size of package.</p>
<p><tt class="docutils literal">Step - 1:</tt></p>
@@ -1363,9 +1395,9 @@ Simply use the <tt class="docutils literal"><span class="pre">debian-tests-data<
For further reading, check <a class="reference external" href="https://wiki.debian.org/Javascript/GroupSourcesTutorial#Manual_way">Javascript Team Embedding wiki</a></p>
</div>
<div class="section" id="faq">
-<h1><a class="toc-backref" href="#toc-entry-64">FAQ</a></h1>
+<h1><a class="toc-backref" href="#toc-entry-65">FAQ</a></h1>
<div class="section" id="how-to-easily-help-upstream-exactly-reproduce-build-test-errors-that-may-be-specific-to-debian">
-<span id="autobuilder"></span><h2><a class="toc-backref" href="#toc-entry-65">How to easily help upstream exactly reproduce build/test errors that may be specific to Debian?</a></h2>
+<span id="autobuilder"></span><h2><a class="toc-backref" href="#toc-entry-66">How to easily help upstream exactly reproduce build/test errors that may be specific to Debian?</a></h2>
<p>For packages already uploaded, you can adapt the Dockerfile below to <a class="reference external" href="https://github.com/sunpy/sunpy/issues/7550#issue-2225805770">share with
upstream</a> so
they can see the error and be able to inspect and troubleshoot with the exact
@@ -1389,7 +1421,7 @@ option to <tt class="docutils literal">docker build</tt> (or <tt class="docutils
architecture, and <tt class="docutils literal">linux/mips64le</tt> for mips64**el**.</p>
</div>
<div class="section" id="what-to-do-if-a-large-package-does-not-build-on-a-specific-autobuilder-architecture">
-<h2><a class="toc-backref" href="#toc-entry-66">What to do if a large package does not build on a specific autobuilder architecture?</a></h2>
+<h2><a class="toc-backref" href="#toc-entry-67">What to do if a large package does not build on a specific autobuilder architecture?</a></h2>
<p>Some of our target packages are large regarding memory consumption or
requiring more computing power to build on not so powerful
architectures. Since the Debian autobuilder infrastructure consists of
=====================================
policy.rst
=====================================
@@ -697,17 +697,26 @@ Policy
`team
upload <https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-team-upload>`__.
-5. **Standards-Version.**
+
+5. **Build-Depends.**
+
+ For new packages of tools that produce architecture-dependant binary packages
+ (anything besides ``Architecture: all``), then the following dependencies
+ should be listed to skip building on non-64-bit and non-little-endian
+ architectures: ``architecture-is-64-bit, architecture-is-little-endian``.
+
+
+6. **Standards-Version.**
Please always use the latest unless there are concerns for
backporting. If no changes are needed, please indicate this fact in
the changelog, and increment the value of the field.
-6. **Homepage.**
+7. **Homepage.**
should be documented whenever possible
-7. **Vcs-Git: and Vcs-Browser:.**
+8. **Vcs-Git: and Vcs-Browser:.**
Please use the following templates, and refer to the Debian Policy
`§ 5.6.26 <https://www.debian.org/doc/debian-policy/#version-control-system-vcs-fields>`__
@@ -718,7 +727,7 @@ Policy
Vcs-Browser: https://salsa.debian.org/med-team/<package>
Vcs-Git: https://salsa.debian.org/med-team/<package>.git
-8. **Testsuite: autopkgtest.**
+9. **Testsuite: autopkgtest.**
Field and value to declare that a testsuite compatible with
`autopkgtest <http://dep.debian.net/deps/dep8/>`__ is available. Such
@@ -726,6 +735,10 @@ Policy
autopkgtest package or the ``sadt`` command from the devscripts
package.
+10. **Rules-Requires-Root.**
+
+ Should be ``no``, if possible.
+
It is a very good idea to use ``Config::Model`` to unify the formatting
of ``debian/control``. To do so make sure you have installed
@@ -1147,6 +1160,29 @@ Please see ``man 1 quilt`` to have a comprehensive list of commands
and the `UsingQuilt <https://wiki.debian.org/UsingQuilt>`__ page on
the Debian Wiki.
+Handling non-trivial issues on less-popular architectures
+---------------------------------------------------------
+
+Given that Debian-Med is targeting the use cases of "medical practice and
+research" and medical institutions and researchers are almost entirely running
+on ``amd64`` and ``arm64`` systems as of 2024, and that there is no tradition
+of big-endian computing in the biomedical and life sciences, then we choose to
+allow ourselves to restrict the architectures where scientific tools and
+applications packaged by the Debian-Med team are built.
+
+If any package maintained by the Debian-Med team has a non-trivial isssue on
+architectures that are unlikely to be needed by our users, then removal of the
+binary packages from those architectures should happen, subject to the following:
+
+1. If any of the binary packages of the targeted source package are
+ reverse-dependencies of non-Debian-Med team packages (even indirectly), then
+ such a removal must be coordinated and approved by the other teams or
+ individual maintainers.
+2. Avoiding building on the problematic architectures by adding a
+ build-dependency on ``architecture-is-64-bit`` and/or
+ ``architecture-is-little-endian`` should be done instead of restricting the
+ ``Architecture`` list, if that isn't too overbroad.
+
Embedding Large Test Data
=========================
View it on GitLab: https://salsa.debian.org/med-team/policy/-/compare/736146fa121cb5430a67e8a0561f0293016f3ca1...4179a7acac5ecd98fd1fa7eeab0f2644cd59424a
--
View it on GitLab: https://salsa.debian.org/med-team/policy/-/compare/736146fa121cb5430a67e8a0561f0293016f3ca1...4179a7acac5ecd98fd1fa7eeab0f2644cd59424a
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-commit/attachments/20240421/ec13adcf/attachment-0001.htm>
More information about the debian-med-commit
mailing list