This is the mail archive of the
mailing list for the Cygwin project.
Re: Dedup x86/x86_64 --> noarch
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 09 May 2016 18:42:57 +0200
- Subject: Re: Dedup x86/x86_64 --> noarch
- Authentication-results: sourceware.org; auth=none
- References: <87zistg99v dot fsf at Rainer dot invalid> <571B539D dot 4050304 at dronecode dot org dot uk> <87r3dwo1aj dot fsf at Rainer dot invalid> <20160423153230 dot GK15916 at calimero dot vinschen dot de> <87mvoknxew dot fsf at Rainer dot invalid> <c44367f6-466a-ae50-e6e9-6b6f3e866d2a at dronecode dot org dot uk>
Jon Turney writes:
> I think 'generally' is over-stating the case, the vast majority of
> source packages should be arch-less.
I said "not generally", which I think makes a slightly less sweeping
statement. In any case, I just wanted to point out that some of the
existing source packages have differences between the two arches that
are not all trivial to remove (texlive, for whatever reason seems to
have arch specific source archives, for instance).
> If the source package really is arch-specific, then it should be
> marked so with ARCH 
This is currently making the whole build including all sub-packages
noarch. There is currently no way to specify arch on a sub-package
granularity and the source package is implied by cygport anyway.
> If it contains arch-specific patches, they should be made conditional
> on ARCH.
Yes, that's the way to go in this case. That wouldn't work in cases
where the sources themselves are already different, unless you suggest
that the source archive itself should be arch-dependent. In that case
we'd have the interesting problem that cygport needs to recognize that
it should package the source for the other arch in the same source
package just to make the result non-arch-specific.
> But yes, this is not straightforward because the way we generate
> source packages at the moment means there is no guarantee that the
> same source package is used to build the different arch variants.
That is fixable as long as it can be done by cygport. I'm more worried
about those packages that still use a different packaging system (I know
of Jari's, and maybe one or the other odd package is still built by hand)
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Blofeld: