On Wed, Jul 02, 2025 at 10:06:45PM +0100, Jon Turney via Cygwin-apps wrote: > > 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
Anecdote (n=1): for a long time, I manually built packages as I did not realize that the automated system was both available to me, as well as easy to use. I now use the automated system to build lighttpd for Cygwin. > Any questions/thoughts/concerns? I agree with you and suggest that "stop sftp package uploads" is not a question to be asked, but rather a question of how to roll the change out. Initially, I recommend forcing use of the automated system on everyone, but with a procedure to request access to the (current) manual process. This will limit the accounts/packages which can build manually, and can also help identify any as-yet-unknown shortcomings of the automated system. It will also help identify less-well-written software; circular dependencies are bad, m'kay? :) The automated system does not prevent people from building and testing manually before pushing the intended changes to the package git repo. Cheers, Glenn
