On Thu, 21 Jul 2022 at 10:44:26 +0200, Marc Haber wrote:
> for a few years now, the Debian archive wants to see source-only
> uploads. This is not documented in the Developer's Reference and also
> now in the New Maintainer's Guide. It should be there.
>
> Also, it should be documented that the first upload of a new package to
> debian MUST be a source+binary upload. Arch all packages need another
> source-only upload after being accepted into the archive to be allowed
> to migrate to testing.
I've had the attached sitting in my outbox for a while and I think it's at
least a good start towards what Marc requests?
I have deliberately not documented the precise meaning of needing to
include binary packages for NEW, on the basis that the conservative thing
to do is to include a complete set (debuild --full). My understanding is
that *technically*, the upload does not need to include *every* binary
package, but that the ftp team would prefer uploads to NEW to include
everything from debuild --full, except in rare special cases such as
the kernel, whose maintainers already know what all the tradeoffs are.
Similarly, I have deliberately been a bit vague about whether uploads
that will add a package to a suite other than unstable/experimental
need binaries, because I don't know whether they do or
not. unstable/experimental NEW definitely needs binaries, I *think*
backports-NEW also needs binaries but I'm not sure, but I think new
additions to -security can/should be source-only?
I have also not attempted to improve ยง5.10 "Porting and being ported",
which seems to have been written from a circa 1998 perspective where all
maintainers uploaded source+i386, binaries for other architectures were
often hand-built by porting teams, and the ability for a package to be
autobuilt successfully was somewhere between "optional but recommended"
and "newly required". It could probably benefit from restructuring or a
rewrite, but I don't think I'm the right writer for that.
> I THINK that arch any packages get an automatic binNMU to avoid that.
My understanding is that the release team often schedule a binNMU to
be helpful, but it is not automatic. We can give simpler advice if we
ignore these binNMUs, which seems better to me anyway - maintainers of
source packages with at least one "Architecture: all" binary package
have to do a sourceful upload regardless, and I'd prefer to encourage
maintainers to be responsible for their packages' migration to testing
rather than centralising that responsibility into the release team.
smcv
>From 96ea2e40f43ce32895d3d2a30e1b5c3319aa1540 Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Mon, 1 Nov 2021 23:30:12 +0000
Subject: [PATCH] Recommend source-only uploads when possible, and describe
when they're not
Closes: #1015784
---
source/pkgs.rst | 58 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/source/pkgs.rst b/source/pkgs.rst
index 11f28cd..7f35e77 100644
--- a/source/pkgs.rst
+++ b/source/pkgs.rst
@@ -336,6 +336,64 @@ details.
Uploading a package
================================================================================================================================
+Source and binary uploads
+--------------------------------------------------------------------------------------------------------------------------------
+
+Each upload to Debian consists of a signed ``.changes`` file describing
+the requested change to the archive, plus the source and binary package
+files that are referenced by the ``.changes`` file.
+
+If possible, the version of a package that is uploaded should be a
+source-only changes file.
+These are typically named ``*_source.changes``, and reference the source
+package, but no binary ``.deb`` or ``.udeb`` packages.
+All of the corresponding architecture-dependent and architecture-independent
+binary packages, for all architectures, will be built automatically by
+the build daemons in a controlled and predictable environment
+(see :ref:`wanna-build` for more details).
+However, there are several situations where this is not possible.
+
+The first upload of a new source package (see :ref:`newpackage`)
+must include binary packages, so that they can be reviewed by the
+archive administrators before they are added to Debian.
+
+If new binary packages are added to an existing source package, then the
+first upload that lists the new binary packages in ``debian/control``
+must include binary packages, again so that they can be reviewed by the
+archive administrators before they are added to Debian.
+It is preferred for these uploads to be done via the ``experimental``
+suite.
+
+Uploads that will be held for review in other queues, such as packages
+being added to the ``*-backports`` suites, might also require inclusion
+of binary packages.
+
+The build daemons will automatically attempt to build any ``main`` or
+``contrib`` package for which the build-dependencies are available.
+Packages in ``non-free`` will not be built by the build daemons unless
+the package has been marked as suitable for auto-building
+(see :ref:`non-free-buildd`).
+
+The build daemons only install build-dependencies from the ``main``
+archive area.
+This means that if a source package has build-dependencies that are
+in the ``contrib`` or ``non-free`` archive areas, then uploads of that
+package need to include prebuilt binary packages for every architecture
+that will be supported.
+By definition this can only be the case for source packages that are
+themselves in the ``contrib`` or ``non-free`` archive areas.
+
+Bootstrapping a new architecture, or a new version of a package with
+circular dependencies (such as a self-hosting compiler), will sometimes
+also require an upload that includes binary packages.
+
+Binary packages in the ``main`` archive area that were not built by
+Debian's official build daemons will not usually be allowed to migrate
+from ``unstable`` to ``testing``, so an upload that contains binary
+packages built by the package's maintainer must usually be followed by
+a source-only upload after the binary upload has been accepted.
+This restriction does not apply to ``contrib`` or ``non-free`` packages.
+
.. _upload-ftp-master:
Uploading to ``ftp-master``
--
2.38.1
