Moving packages between arch and noarch

[Jon Turney <jon.turney@dronecode.org.uk>]

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)