public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: Dedup x86/x86_64 --> noarch
Date: Mon, 09 May 2016 16:43:00 -0000	[thread overview]
Message-ID: <87d1ovqj1q.fsf@Rainer.invalid> (raw)
In-Reply-To: <c44367f6-466a-ae50-e6e9-6b6f3e866d2a@dronecode.org.uk> (Jon	Turney's message of "Mon, 9 May 2016 15:38:23 +0100")

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 [1]

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)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

  reply	other threads:[~2016-05-09 16:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-16 10:04 Achim Gratz
2016-04-18 19:45 ` Achim Gratz
2016-04-23 10:51 ` Jon Turney
2016-04-23 11:19   ` Achim Gratz
2016-04-23 14:19   ` Achim Gratz
2016-04-23 15:32     ` Corinna Vinschen
2016-04-23 15:43       ` Achim Gratz
2016-05-09 14:38         ` Jon Turney
2016-05-09 16:43           ` Achim Gratz [this message]
2016-05-09 14:18     ` Jon Turney
2016-05-09 16:45       ` Achim Gratz
2016-05-09 22:41 ` Andrew Schulman
2016-05-10  5:44   ` Achim Gratz
2016-05-10  6:20     ` Andrew Schulman
2016-05-11 18:59       ` Jon Turney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1ovqj1q.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).