So, to follow on from the points raised in the thread ending [1], and
perhaps start a discussion:
Having developers build executable packages locally and then upload them
doesn't really meet contemporary standards.
Given my druthers, I'd just disable sftp package uploads right now, and
make you all use the janky "build service" I hacked together in a few
spare weekends.
Amongst the advantages this has:
* Ensures that the packaging git repo is updated when the package is.
* Ensures that the source package is complete; and that the build works
and is repeatable.
* Ensures that the package is built in a sterile environment.
* Ensures that the package is serially developed in the git main branch
(so when someone does a NMU, they don't also need to remember to
explicitly communicate any changes made to the maintainer so they don't
drop off again in the next release...)
* Transparency about, and some degree of auditability on how, the
contents of the install package are generated.
* The way we provide a chrooted sftp session for uploads is weird and
non-standard and this means sourceware no longer has to support it.
(A related consideration is that this probably also helps if/when we
want to start providing arm64 packages (which will otherwise entail all
the problems we had when x86_64 started being a thing - but at least in
that case, most maintainers had the necessary hardware, if not the
needed OS) - The alternative seems to be providing numerous cross-build
packages, which doesn't seem like a good use of anyone's time...)
Unfortunately, there are some issues with my half-assed replacement:
* It relies on free CI services (GitHub and AppVeyor) to do the actual
builds, which might be withdrawn or start charging.
* In particular, github requires an account to view the logs, which is a
sticking point for some people.
* There's a number of problems with the current implementation: For a
start it's a synchronous daisy-chain of actions, which isn't tolerant of
intermittent connectivity or other transient problems.
* The "tokens" which can specified to control options in it are an
ad-hoc mess. Idk what the ideal solution is, but the names of those
options all need rethinking for a start...
* If you want to rebuild A and then B which requires the new B, you have
to guess when to submit the build for B. (perhaps it needs private
access to the repo rather than using a mirror, to ensure the copy it's
looking at is up to date, but even then...)
* Some packages have circular dependencies, requiring some bootstrapping
build of package A, using that to build B, before returning to rebuild
package A properly with B available. This is completely unaccounted for
in the current model of doing things.
* There are a couple of packagers using their own handcrafted packaging
rather than cygport.
I'll be reaching out the those soon to discuss what can (reasonably) be
done to accommodate them.
Any questions/thoughts/concerns?
[1] https://cygwin.com/pipermail/cygwin-apps/2025-June/044388.html
