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
|
