On 9/5/2010 8:57 PM, Chris Johns wrote:
> On 6/09/10 10:11 AM, Charles Wilson wrote:
>> We're working on it, but it's slow going.
> Fantastic and please do not take my confusion as being critical. I am
> happy to see these packages appearing. Well done to all involved.
>> As it happens, I just
>> published the manifests for perl and its prerequisites about an hour
> The update worked and I have it. Nice.
>> Once they have propagated to all the sf mirrors, you should be
>> able to do the following:
>> mingw-get update
> Does a list of commands for mingw-get exist ? I tried:
Unfortunately, no. There is no built-in help (or any other option
parsing, for that matter, yet). Right now, the only docu is in
IMO, the highest priority new "features" are:
1. command line option parsing, esp. --help/-h/-?
2. 'mingw-get uninstall a-package-specification'
3. 'mingw-get upgrade a-package-specification' (this is just
"uninstall what I have and install the latest, if newer; otherwise
do nothing" so it's almost free once #2 is implemented.
4. rpm-like query functions:
-q -l (list files in this installed package)
-q -i (tell me about this package )
-q (tell me whether this package is
installed, and what version it is)
-q -a (list all of the packages I have installed)
Now, we don't HAVE to follow the rather cryptic rpm command line
interface, but I figure most folks are familiar enough with rpm
that it's real clear what functionality I'm talking about.
5. manifest query functions:
list all the packages (and their versions) I *could* install
Patches Gratefully Considered...
> mingw-get help
> plus some other variations and I got a fatal error which seems to erase
> the mingw-get executable. Is this a known issue ?
Well, the executable didn't get erased. It just got renamed (and it is a
known issue -- I guess I need to open a tracker item):
mingw-gets last-rites bug [Was: Re: New MinGW and MSYS Installer]
>> mingw-get install msys-perl-bin
> Ah ok so I can get just the binary part. I saw the lic sub-packages for
> licenses. I did not know you could distribute the licenses separate from
> binary images for some licenses .
The idea is that each of the various subcomponents -- dll packages, bin
packages, devel packages -- are ALL covered by the same license. Rather
than ship the license multiple times with each subcomponent (which would
really complicate our installed-file database), we put the relevant
files into a -lic component instead.
All of the manifests have two special markers, for every package:
using these -- eventually -- mingw-get should be able to figure out what
tarball contains the license file associated with what component (and
no, it can't just figure it out from the package name; for instance, the
does NOT have a license file in "bsdtar-*-msys-*-lic.tar" -- because
"bsdtar" is actually built from the libarchive source tarball:
IMO, eventually mingw-get will *automatically* and *always* install the
associated -lic package for everything it installs. But it doesn't do
>  http://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude
We provide the license in downloadable form (specifically in EXACTLY the
same form that every other component of the package is provided in,
installable by our mingw-get installer -- it's not like we require the
end user to go troll thru the -src package or something). We just don't
(yet) *force* the user to download it. Eventually, we probably will...
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.