From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: Dropping various support in future releases - what about Mingw?
Date: Mon, 01 Nov 2021 20:33:32 +0100 [thread overview]
Message-ID: <87tugvzn5f.fsf@Rainer.invalid> (raw)
In-Reply-To: <6a075655-7038-e3ae-8beb-a184600c1265@SystematicSw.ab.ca> (Brian Inglis's message of "Mon, 1 Nov 2021 12:47:08 -0600")
Brian Inglis writes:
> Are they actually being used for anything, in this Cygwin project, or
> the associated Mingw or Wine projects, or are they holdovers from some
> earlier RedHat project?
It would help if you asked questions that are answerable. I have no
idea what you refer to as "they" above. As said before, there are
examples for everything; looking at a few of my own packages: GMP, MPFR
and ISL are needed for the MingW cross-compilation toolchain, ZStd for
setup, cfitsio I have no idea.
> They appear to duplicate the Fedora packages, so who is using which
> package builds?
For a start, have a look which packages require mingw64-* packages. If
you want to drop a package that seems to be unused, just say so and if
it's still needed you will likely hear who is that customer.
> I support packages I use, or libraries used by those packages, as I
> can dogfood them before release.
> I am uncomfortable that I can not do so to test the Mingw devel
> packages I upgrade with their Cygwin equivalents, and know so little
> about their potential uses.
You will never be able to fully vet each package if it has any
complexity, so you either get comforatble with the fact that often the
actual users will have more insight than you or (again) drop
maintenance.
> I mean the Mingw packages are sufficiently different from the Cygwin
> packages that they are effectively another different package, but
> requiring two separate cygport files.
I think of the two cygport files as a wart and the separate Git archives is
another one even though Jon insists we need to keep it.
> The inherit mingw cygclass intended to allow Mingw packages to be
> built like Cygwin packages using the same cygport for both arches, and
> not require two additional cygport files, two git-cygwin-package
> repos, etc.
> It appears to work okay up to the compile but not install, package,
> etc. cygport stages.
I've never started to use this cygclass as it seemed incomplete when it
was introduced, so I can't comment.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
prev parent reply other threads:[~2021-11-01 19:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-31 15:23 Brian Inglis
2021-10-31 23:06 ` Jason Pyeron
2021-11-01 17:33 ` Kyle Marek
2021-11-01 16:27 ` Achim Gratz
2021-11-01 18:47 ` Brian Inglis
2021-11-01 19:33 ` Achim Gratz [this message]
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=87tugvzn5f.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).