On 2025-07-06 03:59, ASSI via Cygwin-apps wrote:
Jon Turney via Cygwin-apps writes:
That's an assertion that would seem to need a few more qualifications to
become true. Fundamentally the underlying VM is actually not under your
control. More specifically cygport already pulls in many dependencies
that you often can't ignore. I've been thinking about doing the Cygwin
install in a way that lets me quickly set up a targeted installation
that really has just the packages required for the build, another one
for test and then of course the one that cygport runs in. That would at
least start to untangle that knot…
* 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.
This is actually artifact storage / deployment, not build. Why do you
(want to?) conflate these, I think that makes the discussion more
complicated. We're anyhow still creating a classical binary package
repo and setup.ini for the users to install Cygwin, not giving them some
Git repo that they can materialize their installation from.
(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.
Also there are limits to what you can do on these free services that my
builds frequently run into. AppVeyor has a 1 hour limit and either the
testing or sometimes even the build does not finish in that time.
I have sometimes had to tweak package builds or checks to try to avoid hangs or
unlimit parallelism to complete within time limits.
As someone who sometimes changes local environments to get builds and tests to
run, I am extremely uncomfortable deploying from a local build, unless it checks
cleaner than the CI build, which I now use when possible.
* In particular, github requires an account to view the logs, which is
a sticking point for some people.
It very much is. I've made that decision based on how GitHub is
perverting Git to become a centralized development model again; and
before GitHub was bought by Microsoft actually.
Also, as an SFC supporter: https://sfconservancy.org/GiveUpGitHub/
Thanks for the ref - we would like to look at using Sware Infra to host our CI
builds - this gives us a clue stick with which to beat recalcitrant or
uncooperative parties ;^>
That would hopefully give us (some) control over the build VMs, plus access to
Windows aarch64 VMs?
* 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...)
This is the actual showstopper. If I can't stage builds and use those
pre-builds to do the final ones, then a new Perl release would become
more or less impossible without it taking either an extremely long time
or leaving a window of when setup.ini is broken for unsuspecting users.
* 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.
Same as above. As I said you will need to have at least one staging
repo of some sorts so that a build can access in addition of the actual
release repo and sequence the builds accordingly.
Wondered when staging releases would come up.
It is normally easier to just build staging as an intermediate step into the
standard process before deploying.
It would be nice if this operation (and perhaps others of significance or merely
informational) could be documented in the cygport help and man page as they are
in the README.
Also nice would be labels for staged packages so new releases of autotools,
cygwin, docbook, gcc, gnome, perl, python, ruby, tcl, texlive, xorg could each
be checked independently without interfering in a single lumped "stage".
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
