[ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
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.

Please do not hesitate to ask if you have any questions.

TIA,
--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

marco atzeri-4


On 11/05/2016 00: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:
>



> Please do not hesitate to ask if you have any questions.
>
> TIA,

So at this stage not the documentation subpackages, but only if all
subpackages are in this category. correct ?

Not so sure if this case fit in your request;
all the language files for tesseract

tesseract-ocr-deu
tesseract-ocr-eng
tesseract-ocr-fra
tesseract-ocr-ita
tesseract-ocr-nld
tesseract-ocr-por
tesseract-ocr-spa
tesseract-ocr-vie
tesseract-training-core
tesseract-training-deu
tesseract-training-eng
tesseract-training-fra
tesseract-training-ita
tesseract-training-nld
tesseract-training-por
tesseract-training-spa
tesseract-training-vie

that are in the same tree of tesseract-ocr but
they have independent minimalist setup.hint hand made.

eg: tesseract-training-eng

$ cat setup.hint
sdesc: "English language files for training tesseract-ocr"
category: Text
requires: tesseract-training-util

Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Thomas Wolff
In reply to this post by Yaakov Selkowitz
Am 11.05.2016 um 00:11 schrieb Yaakov Selkowitz:

> 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.
I wonder why this list or this action does not include all the source
packages, which might even save more disk space than all the others
together.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr├╝ft.
https://www.avast.com/antivirus

Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by marco atzeri-4
On 2016-05-11 00:07, Marco Atzeri wrote:
> So at this stage not the documentation subpackages, but only if all
> subpackages are in this category. correct ?

At this time we are only considering those where all subpackages are
noarch, i.e. ARCH=noarch is (or will be) defined.

> Not so sure if this case fit in your request;
> all the language files for tesseract
[snip]
> that are in the same tree of tesseract-ocr but
> they have independent minimalist setup.hint hand made.

I don't understand, they don't have any external-source: nor a -src
package, so how are they built?

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Andrew Schulman
In reply to this post by Yaakov Selkowitz
Thanks for the headsup.

> 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.

atool
discus
stow

Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
On 2016-05-11 03:15, Andrew Schulman wrote:
> atool
> discus
> stow

Moved to noarch.

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by Thomas Wolff
On 2016-05-11 01:11, Thomas Wolff wrote:
> I wonder why this list or this action does not include all the source
> packages, which might even save more disk space than all the others
> together.

Possibly, but at this time there is not support for separate parts of
packages in different directories.

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

David Stacey
In reply to this post by Yaakov Selkowitz
On 11/05/16 07:17, Yaakov Selkowitz wrote:
> On 2016-05-11 00:07, Marco Atzeri wrote:
>> So at this stage not the documentation subpackages, but only if all
>> subpackages are in this category. correct ?
>
> At this time we are only considering those where all subpackages are
> noarch, i.e. ARCH=noarch is (or will be) defined.


Is it worth making libpoco-doc a separate package? It might be cleaner
that way, as the documentation and source code are in different tarballs
upstream.

Dave.

Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Eric Blake (cygwin)-2
In reply to this post by Yaakov Selkowitz
On 05/10/2016 04:11 PM, 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.
Question: can cygport be enhanced to validate and/or have heuristics for
this?  For example, cygport already has a pass that strips/separates
debuginfo out of binaries compiled by gcc - if any stripping occurs,
then the package is obviously not ARCH=noarch at the moment (down the
road, if we allow noarch by subpackage, that may change slightly, but
you get the idea).

Of my packages, I think that only bash-completion and cvsutils are the
most likely candidates, although I haven't yet fully checked if they are
indeed arch-independent.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Ken Brown-6
In reply to this post by Yaakov Selkowitz
On 5/10/2016 6:11 PM, Yaakov Selkowitz wrote:
> 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.

bzr-fastimport
biber
emacs-auctex
texlive-collection-basic-doc
texlive-collection-bibtexextra-doc
texlive-collection-binextra-doc
texlive-collection-context-doc
texlive-collection-fontsextra
texlive-collection-fontsextra-doc
texlive-collection-fontsrecommended
texlive-collection-fontsrecommended-doc
texlive-collection-fontutils-doc
texlive-collection-genericextra
texlive-collection-genericextra-doc
texlive-collection-genericrecommended
texlive-collection-genericrecommended-doc
texlive-collection-humanities-doc
texlive-collection-langafrican
texlive-collection-langarabic
texlive-collection-langchinese
texlive-collection-langenglish
texlive-collection-langeuropean
texlive-collection-langfrench
texlive-collection-langgerman
texlive-collection-langitalian
texlive-collection-langother
texlive-collection-langportuguese
texlive-collection-langspanish
texlive-collection-latex-doc
texlive-collection-latexextra-doc
texlive-collection-latexrecommended-doc
texlive-collection-luatex-doc
texlive-collection-mathextra-doc
texlive-collection-metapost-doc
texlive-collection-music-doc
texlive-collection-pictures-doc
texlive-collection-plainextra
texlive-collection-pstricks-doc
texlive-collection-publishers
texlive-collection-publishers-doc
texlive-collection-science-doc
texlive-collection-xetex-doc

[There's also python-fastimport, but it looks like someone already
rebuilt this and put it in noarch.]

Ken
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

marco atzeri-4
In reply to this post by Yaakov Selkowitz
On 11/05/2016 08:17, Yaakov Selkowitz wrote:

> On 2016-05-11 00:07, Marco Atzeri wrote:
>> So at this stage not the documentation subpackages, but only if all
>> subpackages are in this category. correct ?
>
> At this time we are only considering those where all subpackages are
> noarch, i.e. ARCH=noarch is (or will be) defined.
>
>> Not so sure if this case fit in your request;
>> all the language files for tesseract
> [snip]
>> that are in the same tree of tesseract-ocr but
>> they have independent minimalist setup.hint hand made.
>
> I don't understand, they don't have any external-source: nor a -src
> package, so how are they built?


just downloaded the specific language data from

https://github.com/tesseract-ocr/tessdata
https://github.com/tesseract-ocr/langdata

copied in a <temp>/usr/share/tessdata
and packaged.

Making a source file was a waste of space as it will be a duplication
of the binary.


In theory I could do a noarch tesseract-ocr-language.cygport
that skips build and for install just copies the data from
the git and than packages the whole.
I doubt that cygport accept an empty SRC_URI, but I have not yet tested it

Regards
Marco





Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by Eric Blake (cygwin)-2
On 2016-05-11 11:36, Eric Blake wrote:
> Question: can cygport be enhanced to validate and/or have heuristics for
> this?

Possibly, I'd have to consider how exactly.

> For example, cygport already has a pass that strips/separates
> debuginfo out of binaries compiled by gcc - if any stripping occurs,
> then the package is obviously not ARCH=noarch at the moment (down the
> road, if we allow noarch by subpackage, that may change slightly, but
> you get the idea).

Cross-compiled libraries (e.g. mingw64-*) are noarch and are stripped
though.

> Of my packages, I think that only bash-completion and cvsutils are the
> most likely candidates, although I haven't yet fully checked if they are
> indeed arch-independent.

They are, and have been moved to noarch accordingly.

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

marco atzeri-4
In reply to this post by Yaakov Selkowitz
On 11/05/2016 00:11, Yaakov Selkowitz wrote:
> Package Maintainers,

>
> 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.
>
> Please do not hesitate to ask if you have any questions.
>
> TIA,

All these are arch independent as contain only scripts
(for the time being)

octave-bim
octave-bsltl
octave-cgi
octave-data-smoothing
octave-dataframe
octave-divand
octave-financial
octave-fpl
octave-fuzzy-logic-toolkit
octave-ga
octave-generate_html
octave-geometry
octave-integration
octave-mvn
octave-ncarray
octave-optics
octave-queueing
octave-secs1d
octave-secs3d
octave-specfun
octave-splines
octave-statistics
octave-vrml

Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by marco atzeri-4
On 2016-05-11 12:56, Marco Atzeri wrote:

> On 11/05/2016 08:17, Yaakov Selkowitz wrote:
>> On 2016-05-11 00:07, Marco Atzeri wrote:
>>> So at this stage not the documentation subpackages, but only if all
>>> subpackages are in this category. correct ?
>>
>> At this time we are only considering those where all subpackages are
>> noarch, i.e. ARCH=noarch is (or will be) defined.
>>
>>> Not so sure if this case fit in your request;
>>> all the language files for tesseract
>> [snip]
>>> that are in the same tree of tesseract-ocr but
>>> they have independent minimalist setup.hint hand made.
>>
>> I don't understand, they don't have any external-source: nor a -src
>> package, so how are they built?
>
>
> just downloaded the specific language data from
>
> https://github.com/tesseract-ocr/tessdata
> https://github.com/tesseract-ocr/langdata

That sounds like two separate source packages then, although you're
welcome to combine them.  FWIW Fedora's package builds these together
with the program itself:

http://pkgs.fedoraproject.org/cgit/rpms/tesseract.git/tree/tesseract.spec

> copied in a <temp>/usr/share/tessdata and packaged.
>
> Making a source file was a waste of space as it will be a duplication
> of the binary.

That's not a factor.  All packages must have a source package, so that
how the binary package(s) are built can be seen and reproduced.

> In theory I could do a noarch tesseract-ocr-language.cygport
> that skips build and for install just copies the data from
> the git and than packages the whole.
> I doubt that cygport accept an empty SRC_URI, but I have not yet tested it

There *is* a SRC_URI: the upstream repo!  If you want to do this
separately, then something along the lines of:

NAME="tesseract-ocr-langdata"
VERSION=3.04.00
RELEASE=1
CATEGORY="Text"
SUMMARY="training files for tesseract-ocr"
DESCRIPTION="Source training data for Tesseract for lots of languages"
HOMEPAGE=
SRC_URI="https://github.com/tesseract-ocr/langdata/archive/${VERSION}/langdata-${VERSION}.tar.gz"
SRC_DIR="langdata-${VERSION}"

ARCH=noarch

PKG_NAMES="tesseract-training-core"
tesseract_training_core_CONTENTS="usr/share/tessdata/training/*.*"
for l in deu:German eng:English fra:French .....
do
   PKG_NAMES+=" tesseract-training-${l%:*}"
   declare tesseract_training_${l%:*}_SUMMARY="${l#*:} ${SUMMARY}"
   declare tesseract_training_${l%:*}_REQUIRES="tesseract-training-core"
   declare
tesseract_training_${l%:*}_CONTENTS="usr/share/tessdata/training/${l%:*}/"
done

src_compile() { :; }

src_install() {
         dodir /usr/share/tessdata/training
         cp -pr ${S}/* ${D}/usr/share/tessdata/training/
}

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by David Stacey
On 2016-05-11 11:26, David Stacey wrote:

> On 11/05/16 07:17, Yaakov Selkowitz wrote:
>> On 2016-05-11 00:07, Marco Atzeri wrote:
>>> So at this stage not the documentation subpackages, but only if all
>>> subpackages are in this category. correct ?
>>
>> At this time we are only considering those where all subpackages are
>> noarch, i.e. ARCH=noarch is (or will be) defined.
>
> Is it worth making libpoco-doc a separate package? It might be cleaner
> that way, as the documentation and source code are in different tarballs
> upstream.

Your call, it doesn't appear that anything is gained from building it
together with poco itself.  I'd name the sources poco-doc and either:

OBSOLETES=libpoco-doc

or:

PKG_NAMES="libpoco-doc"
libpoco_doc_CONTENTS="usr/share/doc/poco/html/"

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by Ken Brown-6
On 2016-05-11 12:26, Ken Brown wrote:
> On 5/10/2016 6:11 PM, Yaakov Selkowitz wrote:
>> 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.
>
> bzr-fastimport
> biber
> emacs-auctex
> texlive-collection-*-doc

Moved to noarch.

> texlive-collection-fontsextra
> texlive-collection-fontsrecommended
> texlive-collection-genericextra
> texlive-collection-genericrecommended
> texlive-collection-langafrican
> texlive-collection-langarabic
> texlive-collection-langchinese
> texlive-collection-langenglish
> texlive-collection-langeuropean
> texlive-collection-langfrench
> texlive-collection-langgerman
> texlive-collection-langitalian
> texlive-collection-langother
> texlive-collection-langportuguese
> texlive-collection-langspanish
> texlive-collection-plainextra
> texlive-collection-publishers

I haven't moved these yet, but what about the rest of the collections?
IIRC the TEXLIVE_ARCH_PKGS do have CPU-cygwin paths in the "sources",
but are they *really* archful?

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
In reply to this post by marco atzeri-4
On 2016-05-11 13:38, Marco Atzeri wrote:

> On 11/05/2016 00:11, Yaakov Selkowitz wrote:
>> Package Maintainers,
>
>>
>> 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.
>>
>> Please do not hesitate to ask if you have any questions.
>>
>> TIA,
>
> All these are arch independent as contain only scripts
> (for the time being)
>
> octave-bim
> octave-bsltl
> octave-cgi
> octave-data-smoothing
> octave-dataframe
> octave-divand
> octave-financial
> octave-fpl
> octave-fuzzy-logic-toolkit
> octave-ga
> octave-generate_html
> octave-geometry
> octave-integration
> octave-mvn
> octave-ncarray
> octave-optics
> octave-queueing
> octave-secs1d
> octave-secs3d
> octave-specfun
> octave-splines
> octave-statistics
> octave-vrml

But what about the following?

octave-nan
octave-octcdf
octave-stk
octave-tsa

--
Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

marco atzeri-4
On 11/05/2016 22:48, Yaakov Selkowitz wrote:

> On 2016-05-11 13:38, Marco Atzeri wrote:
>> On 11/05/2016 00:11, Yaakov Selkowitz wrote:
>>> Package Maintainers,
>>
>>>
>>> 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.
>>>
>>> Please do not hesitate to ask if you have any questions.
>>>
>>> TIA,
>>
>> All these are arch independent as contain only scripts
>> (for the time being)
>>
>> octave-bim
>> octave-bsltl
>> octave-cgi
>> octave-data-smoothing
>> octave-dataframe
>> octave-divand
>> octave-financial
>> octave-fpl
>> octave-fuzzy-logic-toolkit
>> octave-ga
>> octave-generate_html
>> octave-geometry
>> octave-integration
>> octave-mvn
>> octave-ncarray
>> octave-optics
>> octave-queueing
>> octave-secs1d
>> octave-secs3d
>> octave-specfun
>> octave-splines
>> octave-statistics
>> octave-vrml
>
> But what about the following?
>
> octave-nan
> octave-octcdf
> octave-stk
> octave-tsa
>


/usr/lib/octave/packages/
contains the arch specific in this case in mex variant.


octave-octcdf is obsolete and empty.






Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Yaakov Selkowitz
On 2016-05-11 16:02, Marco Atzeri wrote:

> On 11/05/2016 22:48, Yaakov Selkowitz wrote:
>> But what about the following?
>>
>> octave-nan
>> octave-octcdf
>> octave-stk
>> octave-tsa
>
> /usr/lib/octave/packages/
> contains the arch specific in this case in mex variant.
Oops, it seems cygport knows nothing of this, only of .oct.  Could you
please try rebuilding one of those with the following patch to cygport
and see if it behaves properly (.mex are executable, stripped, and
binary dependencies listed in requires:)?

--
Yaakov

0001-Handle-Octave-.mex-extensions-as-DLLs.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Ken Brown-6
In reply to this post by Yaakov Selkowitz
On 5/11/2016 4:35 PM, Yaakov Selkowitz wrote:
> I haven't moved these yet, but what about the rest of the collections? IIRC the
> TEXLIVE_ARCH_PKGS do have CPU-cygwin paths in the "sources", but are they
> *really* archful?

No, the only issue is the sources.  As it stands, if someone downloads the
source from one arch and tries to build on the other, cygport will complain
about missing source packages.  Of course, running 'cygport fetch' will fix
that, so it's not a big deal.

Maybe in the future we should add the TEXLIVE_ARCH_PKGS for both CPUs to the
sources, and then there's no issue at all.

Ken
1234