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: Planned setup.ini changes for early 2018
Date: Tue, 16 Jan 2018 18:12:00 -0000	[thread overview]
Message-ID: <87efmp8yg6.fsf@Rainer.invalid> (raw)
In-Reply-To: <92b5ec62-0c4a-ad37-1c10-164db0119879@dronecode.org.uk> (Jon	Turney's message of "Mon, 15 Jan 2018 19:01:35 +0000")

Jon Turney writes:
> The purpose of my original email is to start that discussion.

Well, sorry then for not recognizing that, but from your other answers
in this thread I've got the impression src/ is a done deal that you
didn't want to discuss.

> If I've understood correctly, your objection is that this will break
> installing source packages from mirrors which choose to mirror
> selected subdirectories (e.g. x86_64/ and noarch/).

My personal objection is that it will add another two hours to mirroring
the Cygwin repo via a HTTP proxy (or I just give up on mirroring the
sources).  But yes, not breaking things for folks who try to be nice to
mirror operators is next on my list.  Then come the mirror operators
themselves.  I must admit I hadn't considered the Cygwin Time Machine,
this adds another twist that I haven't fully thought through yet.

> I guess I consider that counterbalanced by the ability to selectively
> not mirror src/.

I don't, due to the conspicUous naming of the source archive files that
effect is easily achieved by all mirroring methods that I have
personally used.  So it doesn't really add any value that I can see to
counterbalance the other ripple effects it will have.

Unfortunately I don't have a lot of time on my hands right now, but I
think (very preliminarily) that aside from keeping the directory
structure intact, we should also keep the old setup.ini as-is (not just
compatible) and instead move the "new" setup.ini one level up and have
it encompass both supported architectures using a more compact syntax.
It should be possible to generate the "old" x86{,_64}/setup.ini by
transforming the "new" setup.ini so you can hopefully drop some more
baggage in calm.  The main benefit of using a modified format would be
to not have the redundant information in it as the current format would
need to carry.  As long as we keep the old format around that redundancy
is effectively still with us, but we can isolate it more easily.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

  reply	other threads:[~2018-01-16 18:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 22:44 Jon Turney
2018-01-10 23:27 ` David Stacey
2018-01-13 17:21   ` Jon Turney
2018-01-11 17:55 ` Peter A. Castro
2018-01-12 15:48   ` Jon Turney
2018-01-12 18:13     ` Peter A. Castro
2018-01-13 17:22       ` Jon Turney
2018-01-11 18:30 ` Achim Gratz
2018-01-13 18:43   ` Achim Gratz
2018-01-13 18:35 ` Achim Gratz
2018-01-15 19:02   ` Jon Turney
2018-01-16 18:12     ` Achim Gratz [this message]
2018-01-22 23:13 ` Jon Turney
2018-01-23 18:30   ` Achim Gratz
2018-01-24 20:30     ` Jon Turney
2018-01-24 20:57       ` Achim Gratz
2018-01-28 15:07   ` Jon Turney
2018-03-01 16:01 ` Jon Turney
2018-03-01 16:39   ` Marco Atzeri
2018-03-01 17:02     ` Jon Turney
2019-05-30 14:08   ` 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=87efmp8yg6.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).