From: MateAR.eu <in...@ma...> - 2011-05-29 15:24:04
|
Hi all, The very first release of MinGW-MSYS Installer is available on SourceForge (http://sourceforge.net/projects/mingwbundle/). Since it is the first release we invite you to try it and we welcome comments/feedback/suggestions for improvement/etc. This bundle setup deploys the latest MinGW and MSYS core components as well as some additional libraries. It does not require Internet connection and it is ready to use. We hope you find this contribution to MinGW Project useful and we look forward to hearing from you soon. Thanks in advance. Sergio. |
From: Earnie <ea...@us...> - 2011-05-29 16:46:01
|
MateAR.eu wrote: > Hi all, > > The very first release of MinGW-MSYS Installer is available on > SourceForge (http://sourceforge.net/projects/mingwbundle/). Since it is > the first release we invite you to try it and we welcome > comments/feedback/suggestions for improvement/etc. This bundle setup > deploys the latest MinGW and MSYS core components as well as some > additional libraries. It does not require Internet connection and it is > ready to use. I find it a poor waste of time and a waste of SourceForge resources and poor netiquette to announce this project here. Why do we need YA distribution of MinGW and MSYS which is a large zip file of software. Note, you are in violation of the license unless that 76.9 M package also contains the source of each binary file which I find unlikely. -- Earnie -- http://www.for-my-kids.com |
From: Jack A. <ef...@gm...> - 2011-05-30 13:23:49
|
On Mon, May 30, 2011 at 2:45 AM, Earnie <ea...@us...> wrote: [snip] > Note, you are in violation of the license unless that 76.9 M package > also contains the source of each binary file which I find unlikely. aren't there are a few examples of other GPL bundles that don't include the source? ta, jack. |
From: Tom S. <tsm...@gm...> - 2011-05-30 17:10:25
|
On Mon, May 30, 2011 at 6:23 AM, Jack Andrews <ef...@gm...> wrote: > On Mon, May 30, 2011 at 2:45 AM, Earnie <ea...@us...> > wrote: > [snip] > > Note, you are in violation of the license unless that 76.9 M package > > also contains the source of each binary file which I find unlikely. > > aren't there are a few examples of other GPL bundles that don't > include the source? > > You need to give a link pointing to the GPL source code that you used and the user can download. Tom |
From: Keith M. <kei...@us...> - 2011-05-30 18:13:41
|
On 30/05/11 18:10, Tom Smith wrote: > On Mon, May 30, 2011 at 6:23 AM, Jack Andrews <ef...@gm...> wrote: > >> On Mon, May 30, 2011 at 2:45 AM, Earnie <ea...@us...> >> wrote: >> [snip] >>> Note, you are in violation of the license unless that 76.9 M package >>> also contains the source of each binary file which I find unlikely. >> >> aren't there are a few examples of other GPL bundles that don't >> include the source? >> >> > You need to give a link pointing to the GPL source code that you used and > the user can download. And that link needs to point to source code which YOU, as distributor of the binary, host and maintain YOURSELF; it is NOT sufficient to refer to source hosted and maintained by someone else. Let's make this absolutely clear: this mega-tarball is neither sanctioned nor supported by MinGW.org, (whom this ML serves). By all means use it, if it suits your purposes, but if you run into any problem with it, please don't bother to ask us for support. FTR, the primary motivation behind the development of mingw-get is the unwieldy nature of such mega-tarballs, which in our experience aren't really a convenience to the end user. Furthermore, we find that they rapidly become unmaintainable, and outdated. As a final point, while we will accept a one-time notification of the availability of such a mega-tarball, we take a dim view of persistent promotion of them. Any user actively and persistently promoting such an unsupported package risks rescission of their posting rights. -- Regards, Keith. |
From: Xiaofan C. <xia...@gm...> - 2011-05-31 01:07:25
|
On Tue, May 31, 2011 at 2:13 AM, Keith Marshall <kei...@us...> wrote: > Let's make this absolutely clear: this mega-tarball is neither > sanctioned nor supported by MinGW.org, (whom this ML serves). By all > means use it, if it suits your purposes, but if you run into any problem > with it, please don't bother to ask us for support. > > FTR, the primary motivation behind the development of mingw-get is the > unwieldy nature of such mega-tarballs, which in our experience aren't > really a convenience to the end user. Furthermore, we find that they > rapidly become unmaintainable, and outdated. > Good idea. Hopefully the MinGW-w64 people will also adopt mingw-get and not to release tar ball like the following MSys package. http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/ -- Xiaofan |
From: JonY <jo...@us...> - 2011-05-31 01:30:05
Attachments:
signature.asc
0xED74C077.asc
|
On 5/31/2011 09:07, Xiaofan Chen wrote: > On Tue, May 31, 2011 at 2:13 AM, Keith Marshall > <kei...@us...> wrote: >> Let's make this absolutely clear: this mega-tarball is neither >> sanctioned nor supported by MinGW.org, (whom this ML serves). By all >> means use it, if it suits your purposes, but if you run into any problem >> with it, please don't bother to ask us for support. >> >> FTR, the primary motivation behind the development of mingw-get is the >> unwieldy nature of such mega-tarballs, which in our experience aren't >> really a convenience to the end user. Furthermore, we find that they >> rapidly become unmaintainable, and outdated. >> > > Good idea. Hopefully the MinGW-w64 people will also > adopt mingw-get and not to release tar ball like the following > MSys package. > http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/ Personally, I'd prefer a quick and dirty unpack and run tarball like Ruben's tarball. It works pretty well in network and security restricted environments. At this point its rather mingw(-w64) agnostic, so you can throw in whichever you prefer and quickly get a working MSYS+MINGW setuo. |
From: Fabian G. <fa...@gr...> - 2011-05-31 12:35:05
|
Am 29.05.2011 09:45, schrieb Earnie: > I find it a poor waste of time and a waste of SourceForge resources and > poor netiquette to announce this project here. Why do we need YA > distribution of MinGW and MSYS which is a large zip file of software. I agree, especially since the time saved against the regular installation procedure via mingw-get may be in the order of five minutes. Please note that the mingw64 project already provides a similar monolithic zip archive (that contains only MSYS, though) here: <http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/> - Fabian |
From: Earnie <ea...@us...> - 2011-05-31 13:21:39
|
Fabian Greffrath wrote: > Please note that the mingw64 project already provides a similar > monolithic zip archive (that contains only MSYS, though) here: > > <http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/> > I am aware of it. It was first created before mingw-get was ready to do the installation and the lack of an installer to get the correct files on start from a massive pick list. Now that mingw-get can install it, perhaps that file can be eliminated, especially if mingw-64 project can adopt and adapt to mingw-get for their install method. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2011-05-31 14:48:06
|
On 5/31/2011 9:21 AM, Earnie wrote: > Fabian Greffrath wrote: >> Please note that the mingw64 project already provides a similar >> monolithic zip archive (that contains only MSYS, though) here: >> >> <http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/> >> > > I am aware of it. It was first created before mingw-get was ready to do > the installation and the lack of an installer to get the correct files > on start from a massive pick list. Now that mingw-get can install it, > perhaps that file can be eliminated, especially if mingw-64 project can > adopt and adapt to mingw-get for their install method. > I mentioned this possibility, as an opportunity for more mingw.org-mingw64.sf cooperation, to NS six months ago or so, but there are still some missing pieces in mingw-get, so I haven't brought it up again since (until this thread). e.g. multi-repository use -- what if both repositories specify "package-list.xml"? OR, specify different "msys-foo.xml" if siteB wants to use a customized version? Somehow, the metadata from multiple repositories needs to be intelligently merged, which would also (perhaps?) require a mechanism in profile.xml to specify "who wins if there is a tie" -- that is, BOTH siteA and siteB specify a "msys-foo-1.2.3-1" package (for instance, if siteB wants a customized build of 'foo' for some reason, with possibly different <requires />). However, that's a rather large effort, and Keith's time has been limited (and nobody else really understands the innards of mingw-get, without docu; c.f. "you want Keith to work on docu, or finishing the code?"). Plus, we need to ensure that most/all of the kinks are worked out of mingw-get in its normal single-repo usage case, first, and become feature-complete...and that still hasn't stabilized yet, really. So...for now, there's no reason for us to even think about mingw64.sf's monolithic msys .zip file. If it works for them, and they're happy, and all the GPL i's/t's are dotted/crossed... ===== Now, returning to the original OP's announcement...there does seem to be a GPL issue with that bundle. The OP could easily resolve it by collecting *our* -src tarballs for all of the components in his bundle, as well as the sources for his "some additional libraries", and zip'ping those up into a msys-bundle-src.zip Now, I'd prefer if the "bundle" were mingw-get compatible -- that is, is actually reflects a snapshot of an installation that was primarily created using mingw-get. That way, once his users installed the bundle, they could at least update the components that were derived from mingw.org packages via mingw-get (they'd be on their own for updating his "some additional libraries"). If that were the case, then I have no conceptual problem with a bundle like this -- as long as I don't have to keep it up to date, or support the "some additional libraries". Alternatively, my earlier proposal for a mingw-get "download" (and download-src) action would make preparing internet-less install bundles like this So Easy A Caveman Could Do It, and would make actual ".zip" files unnecessary. In fact, our existing mingw-get-inst installer could be *quickly* adapted to handle this sort of bundle, as well. All it takes is: (a) remove the step and the wizard page where mingw-get-inst tries to call 'mingw-get update', and (b) run "mingw-get download <giant list of packages>" and "mingw-get download-src <giant list of packages>" before compiling the installer. (*) Naturally, I'd prefer that the name of the installer be changed, and various disclaimers like 'not provided or supported by mingw.org team' were added... (*) Our caveman would then probably want to move tmp/var/cache/mingw-get/data/*-src.tar.* somewhere else, so that caveman-mingw-bundle.exe installer isn't TOO huge. However, he'd then need to add all those -src tarballs to the caveman-mingw-bundle-src.tar package, along with his cavemen-mingw-get-inst.iss InnoSetup script, to make the GPL happy. You know what? Once mingw-get supports download and download-src, I could probably write a bundle-installer-generator program that simply takes a package list, and automatically creates the installer .exe and -src tarball...then an australopithicus could do it; no caveman needed. -- Chuck |
From: Charles W. <cwi...@us...> - 2011-05-31 02:17:53
|
On 5/30/2011 9:29 PM, JonY wrote: > Personally, I'd prefer a quick and dirty unpack and run tarball like > Ruben's tarball. It works pretty well in network and security restricted > environments. > > At this point its rather mingw(-w64) agnostic, so you can throw in > whichever you prefer and quickly get a working MSYS+MINGW setuo. I think one of the things 'mingw-get' needs is a "download" action, as well as a download-src action -- in which case it would download all the specified (and dependent) tarballs, but not actually install anything. That way, an end-user could do this, on an internet-connected computer: 1. d/l and install mingw-get into some temporary location. 2. update the profile.xml as needed 3. $ mingw-get download package-specs... 4. $ mingw-get download-src package-specs... Then, simply zip up the result and copy to a thumb drive. The result could be unpacked on the restricted computer, and then mingw-get install package-specs would DTRT without any network access. Plus, if the zip was "distributed", the GPL would be automatically satisfied. Also, mingw-get.exe can install msys (by itself) in a mingw$flavor-agnostic manner today (but mingw-get-inst, the silly GUI wrapper, can't). It also would not require much to allow mingw-get to be used to install msys + mingw64-[x86_64|i686]. You guys just need to write some xml fragments like mingw64-i686-binutils.xml etc, post them on the web somewhere along with a mingw64-i686-package-list.xml mingw64-x86_64-package-list.xml and a custom "profile.xml" that points to your repository instead of ours. There might be a few kinks to work out to get multiple simultaneous repositories to work correctly (mingw.org for msys, mingw64.sf for your gcc), but it's do-able. -- Chuck |
From: Xiaofan C. <xia...@gm...> - 2011-05-31 02:45:10
|
On Tue, May 31, 2011 at 10:17 AM, Charles Wilson <cwi...@us...> wrote: > Also, mingw-get.exe can install msys (by itself) in a > mingw$flavor-agnostic manner today (but mingw-get-inst, the silly GUI > wrapper, can't). It also would not require much to allow mingw-get to > be used to install msys + mingw64-[x86_64|i686]. > > You guys just need to write some xml fragments like > mingw64-i686-binutils.xml > etc, post them on the web somewhere along with a > mingw64-i686-package-list.xml > mingw64-x86_64-package-list.xml > and a custom "profile.xml" that points to your repository instead of ours. > > There might be a few kinks to work out to get multiple simultaneous > repositories to work correctly (mingw.org for msys, mingw64.sf for your > gcc), but it's do-able. > Good idea. The only issue is that MinGW-w64 needs to make up the mind of which one to recommend the users to download. Right now it is a bit messy for the MinGW-w64 Sourceforge site. http://sourceforge.net/projects/mingw-w64/files/ So most of the users will probably have better lucks with TDM64. http://tdm-gcc.tdragon.net/download This is also the "preferred" for Windows users according to the Trac Wiki but it is not that obvious from the project website. http://sourceforge.net/apps/trac/mingw-w64/wiki/GeneralUsageInstructions -- Xiaofan |