This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Moving packages between arch and noarch
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: "cygwin-apps at cygwin dot com" <cygwin-apps at cygwin dot com>
- Date: Fri, 14 Jun 2019 16:36:43 +0100
- Subject: Moving packages between arch and noarch
- References: <9de6f042-3510-ef4c-9c2d-90f354244691@cygwin.com>
On 10/05/2016 23:11, Yaakov Selkowitz wrote:
Package Maintainers,
cygport 0.22.0 is on its way to the mirrors. With this release, and
thanks to Jon Turney's continuing work on calm (the replacement for
upset which generates setup.ini), packages marked ARCH=noarch will be
uploaded once under the /noarch/release hierarchy instead of into each
of /x86/release and /x86_64/release. This change is intended to save
disk space and bandwidth for both sourceware and our mirrors.
A package should be marked ARCH=noarch IF AND ONLY IF *all* subpackages
thereof do not contain anything compiled with the *native* gcc, and the
file contents are (or can be) 100% identical for x86 and x86_64.
Examples include, but are not limited to, packages which contain only:
* documentation;
* scripts;
* fonts;
* icon themes;
* other runtime data;
* C/C++ headers without a library;
* libraries for cross-compiler toolchains.
* pure Lua/Perl/Python/Ruby/Tcl modules without C/C++ bindings.
Once you have upgraded to cygport 0.22.0, maintainers MUST email a list
of their package(s) which qualify as noarch AND are already marked
ARCH=noarch or will be with the next release. (Note that inheriting
cross.cygclass implies ARCH=noarch.) A new release is NOT necessary
just to add ARCH=noarch to the .cygport, just that it should be added
locally so as to be included in the next release. We will then move
these packages into /noarch/release on sourceware and acknowledge such,
at which point you are clear to upload future releases.
I recently deployed a calm update which makes this process (and it's
reverse, when a previously noarch package becomes archful) no longer
require any manual steps.
So, going forward, you may build each version of a package with
ARCH=noarch and upload to noarch/, or without, and upload to x86/ and
x86_64/.
(But not both! Attempting to upload a package version which already
exists with different archfullness will be rejected)
(More complex reconfigurations, where packages are split/merged/renamed
still require manual adjustments)