Updated packages available (wave 7)

[Charles Wilson-8]

I've uploaded several new MSYS packages to sourceforge. As always, MSYS
packages should be unpacked under / (that is, C:\msys\1.0) and MinGW
packages should be unpacked under /mingw (that is, C:\MinGW).

As usual, you'll find the new packages at the FRS
https://sourceforge.net/projects/mingw/files/ in the following folders:

   MSYS  coreutils    5.97   (same as existing, just rebuilt/repacked)
   MSYS  bash         3.1.17 (updated from 3.1.0)
   MSYS  make         3.81   (same as existing, just rebuilt/repacked)
   MSYS  core         1.0.11 [1]

Note however, that updating 'bash' and 'core' can't be done from within
an msys environment.  Instead, follow this procedure:

>From an MSYS window:

   $ cd /
   $ bsdtar xf bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
   $ bsdtar xf msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma

Both of these commands will generate errors (unable to replace in-use
files). Next:

   $ cd C:/TEMP
   $ bsdtar xf bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
   $ bsdtar xf msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma

Then, exit all MSYS windows.  From a cmd window (NOT msys!), do this:

   > cd C:\TEMP
   > copy /B bin\msys-1.0.dll C:\msys\1.0\bin
   > copy /B bin\bash.exe     C:\msys\1.0\bash.exe
   > copy /B bin\sh.exe       C:\msys\1.0\sh.exe

And then clean up C:\TEMP if desired.


The new packages satisfy the latest MinGW/MSYS packaging standards,
allowing a more granular installation in keeping with the "minimal"
nature of MinGW/MSYS. See
http://www.mingw.org/PackageIdentificationHOWTO for more information.

However, until an installer capable of managing the granular selections
is available (which will happen eventually), what we have is a whole lot
of packages, which you the user have to download separately and manually
unpack. So what should you install?

Short version: You want all of these -bin packages.  You might want the
coreutils-ext package, and non-english speakers might want the -lang
packages.

Some notes concerning these updates:

coreutils:
===============================
Built with i18n enabled. The translation files are packaged in a
separate -lang tarball, so native English speakers need not download
them. However, the individual tools have libiconv/libintl code linked in
statically, which makes the binaries larger. I figure this is a
reasonable tradeoff, to support non-English speakers.  The size penalty
will go away, once the msys compiler is updated from 2.95.3 to 3.x or
better, which will allow us to build msys-libintl/msys-libiconv as DLLs.

The coreutils-bin package contains the tools that were originally
shipped as part of the msysCORE installation (plus echo.exe, printf.exe,
and pwd.exe -- in the original msysCORE, these were scripts. But scripts
aren't i18n-aware).

There is also a coreutils-ext package, which contains all the OTHER
coreutils executables.

make:
===============================
Built with i18n enabled. The translation files are packaged in a
separate -lang tarball, so native English speakers need not download them.

bash:
===============================
Updated to official upstream patchlevel 17 (but still epoch 3.1. I
didn't try to update to 3.2.x or 4.x. <shudder>).  bash is NOT built
with i18n enabled -- because upstream bash-3.1 does not actually provide
any translations.

[1] "msys core"
===============================
The "msys core" package
      msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma
differs from the existing
      msysCORE-1.0.11-bin.tar.gz
      msysCORE-1.0.11.exe
package in the following ways;

  1) Contains only the MSYS dll and associated scripts, documentation,
     and helper programs -- that is, the stuff that is unique to MSYS,
     and is not already provided by other modularized packages.

  2) The postinstall script has been modified to prefer the .exe's
     shipped by the other -bin packages, rather than preferring wrapper
     scripts.  That is, prefer
         awk.exe echo.exe egrep.exe ex.exe fgrep.exe
         printf.exe pwd.exe rview.exe rvim.exe view.exe
     to script versions (note that usually echo, printf, and pwd are
     shell builtins; this change only makes a difference for those three
     applications when you explicitly execute /bin/foo)

  3) While you COULD generate a -bin package which these characteristics
     and footprint by unpacking the associated base-src package (more
     below) and running `msysbld.sh && msysrls.sh', I didn't do that. (I
     tested that, and it works fine. But:) Instead, the *binaries* in
     this -base-bin package are exact COPIES from the  corresponding
     files in the original msysCORE-1.0.11-bin.tar.gz and
     msysCORE-1.0.11.exe.

     Thus, except for the postinstall script differences and the
     .exe-vs-script issues mentioned above, unpacking this -base-bin
     tarball will give you the same binaries as the original -bin
     package === FOR those binaries that -base-bin actually includes.
     That is, same msys-1.0.dll, identical msysmnt.exe, etc.

Now, the -base-src package differs from the original -src package in the
following ways:

  1) The original -src package included, as required by the GPL, all the
     source code for the add-on packages like bash, make, coreutils,
     rxvt, etc.  Since -base-bin does NOT ship those binaries, the
     -base-src package does not include those sources.  That is:

        rm -rf msysCORE-1.0.11/src/bash-3.1-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/bzip2-1.0.3-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/coreutils-5.97-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/cpmake-3.81-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/diffutils-2.8.7-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/file-4.16-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/findutils-4.3.0-MSYS-1.0.11-3
        rm -rf msysCORE-1.0.11/src/gawk-3.1.5-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/grep-2.4.2-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/gzip-1.2.4a-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/less-358-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/lzma-4.43-MSYS-1.0.11-2
        rm -rf msysCORE-1.0.11/src/m4-1.4.7-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/patch-2.5.4-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/rxvt-2.7.2-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/sed-3.02-MSYS-1.0.11-1
        rm -rf msysCORE-1.0.11/src/tar-1.19.90-MSYS-1.0.11-2
        rm -rf msysCORE-1.0.11/src/texinfo-4.11-MSYS-1.0.11-1

  2) Because of the (new) preference for executables over scripts,
     various files were removed from msysCORE-1.0.11/store:

        rm -f msysCORE-1.0.11/store/noarch/bin/awk      #[gawk-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/bunzip2  #[bzip-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/echo     #[coreutils-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/egrep    #[grep-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/fgrep    #[grep-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/gunzip   #[gzip-bin
        rm -f msysCORE-1.0.11/store/noarch/bin/printf   #[coreutils-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/pwd      #[coreutils-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/texi2dvi #[texinfo-bin]

        rm -f msysCORE-1.0.11/store/noarch/bin/d2u
                                        #[cygutils-dos2unix-bin]
        rm -f msysCORE-1.0.11/store/noarch/bin/u2d
                                        #[cygutils-dos2unix-bin]

  3) config.site is no longer appropriate (it contains mostly
     workarounds for old busted libtool; new hotness libtool
     doesn't need that).  We don't ship it as part of msys-1.0.11
     anyway.  Also, /etc/termcap is now provided by the termcap-bin
     package.

        rm -f msysCORE-1.0.11/store/noarch/etc/config.site
        rm -f msysCORE-1.0.11/store/noarch/etc/termcap

  4) Fix up the packaging .dat files to account for the changes above.

        msysCORE-1.0.11/store/var/dll.dat
        msysCORE-1.0.11/store/var/etc.dat
        msysCORE-1.0.11/store/var/exe.dat
        msysCORE-1.0.11/store/var/misc.dat
        msysCORE-1.0.11/store/var/script.dat
        msysCORE-1.0.11/store/var/share.dat

 5) Updated the build script to create the desired package name, and
    to skip creating an .exe installer.  Update the postinstall script
    as described above.
        msysCORE-1.0.11/msysrls.sh
        msysCORE-1.0.11/store/noarch/pi/pi.sh

The changes in (4) and (5) are in the attached patch. We now possess
completely modularized components, suitable for installation by
mingw-get, once it is ready [*].  At some point I'll set up a wiki page
that lists exactly which packages are necessary for an installation
footprint matching
  (a) the original msysCORE installation
  (b) a separate list describing a basic msysCORE+msysDTK installation
  (c) and yet another list describing an msysCORE+msysDTK+msysDVLPR one

[*] except for msysDVLPR. But that's ok. I imagine that setting up an
msysDVLPR environment will continue to be a manual process, even after
the advent of mingw-get.


FINAL note: if you're trying to mimic mingw-get "by hand", and want to
install msys on a pristine system using only the modularized components,
you'll have to unpack at least msyscore-bin, coreutils-bin, and bash-bin
BEFORE attempting to run /postinstall/pi.bat or pi.sh.  And naturally,
you'll need to use a non-MSYS tar and lzma utility.

--
Chuck

P.S. Here's the list:

bash-3.1.17-2-msys-1.0.11-bin.tar.lzma
bash-3.1.17-2-msys-1.0.11-doc.tar.lzma
bash-3.1.17-2-msys-1.0.11-lic.tar.lzma
bash-3.1.17-2-msys-1.0.11-src.tar.lzma
bash-3.1.17-2-msys.RELEASE_NOTES.txt

make-3.81-2-msys-1.0.11-bin.tar.lzma
make-3.81-2-msys-1.0.11-doc.tar.lzma
make-3.81-2-msys-1.0.11-lang.tar.lzma
make-3.81-2-msys-1.0.11-lic.tar.lzma
make-3.81-2-msys-1.0.11-src.tar.lzma
make-3.81-2-msys.RELEASE_NOTES.txt

coreutils-5.97-2-msys-1.0.11-bin.tar.lzma
coreutils-5.97-2-msys-1.0.11-doc.tar.lzma
coreutils-5.97-2-msys-1.0.11-ext.tar.lzma
coreutils-5.97-2-msys-1.0.11-lang.tar.lzma
coreutils-5.97-2-msys-1.0.11-lic.tar.lzma
coreutils-5.97-2-msys-1.0.11-src.tar.lzma
coreutils-5.97-2-msys.RELEASE_NOTES.txt

msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma
msysCORE-1.0.11-msys-1.0.11-base-src.tar.lzma



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Charles Wilson wrote:

> Then, exit all MSYS windows.  From a cmd window (NOT msys!), do this:
>
>    > cd C:\TEMP
>    > copy /B bin\msys-1.0.dll C:\msys\1.0\bin
>    > copy /B bin\bash.exe     C:\msys\1.0\bash.exe
>    > copy /B bin\sh.exe       C:\msys\1.0\sh.exe

Oops:

   > cd C:\TEMP
   > copy /B bin\msys-1.0.dll C:\msys\1.0\bin\
   > copy /B bin\bash.exe     C:\msys\1.0\bin\
   > copy /B bin\sh.exe       C:\msys\1.0\bin\

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Cesar Strauss-2]

Charles Wilson wrote:

> As usual, you'll find the new packages at the FRS
> https://sourceforge.net/projects/mingw/files/ in the following folders:
>
>    MSYS  coreutils    5.97   (same as existing, just rebuilt/repacked)
>    MSYS  bash         3.1.17 (updated from 3.1.0)
>    MSYS  make         3.81   (same as existing, just rebuilt/repacked)
>    MSYS  core         1.0.11 [1]
>

Thank you very much Chuck, I appreciate it. I am sorry I was not able to
give much help this time.

> bash:
> ===============================
> Updated to official upstream patchlevel 17 (but still epoch 3.1. I
> didn't try to update to 3.2.x or 4.x. <shudder>).

I did try a quick port of the latest Cygwin version, but it did not
behave very well at run-time. I will have to debug it sometime. Also, it
  would be good to have this Cygwin-specific igncr shell option enabled
by default, so CRLF line endings are tolarated on input.

> [1] "msys core"
> ===============================
> The "msys core" package
>       msysCORE-1.0.11-msys-1.0.11-base-bin.tar.lzma
> differs from the existing
>       msysCORE-1.0.11-bin.tar.gz
>       msysCORE-1.0.11.exe
> package in the following ways;
>
>   1) Contains only the MSYS dll and associated scripts, documentation,
>      and helper programs -- that is, the stuff that is unique to MSYS,
>      and is not already provided by other modularized packages.
>

Perhaps it would be a good idea for me to provide the MSYS runtime in
its own package, separated from the basic support files. That way, if I
need to update msys.bat, for instance, I do not need to upload the whole
MSYS source code along with it.

Regards,
Cesar

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Cesar Strauss wrote:
> Thank you very much Chuck, I appreciate it. I am sorry I was not able to
> give much help this time.

N.P.  Nothing else on this front can happen until mingw-get stabilizes,
but I didn't want the lack of a complete set of modularized packages to
hold things up once it does.

>
>> bash:
>
> I did try a quick port of the latest Cygwin version, but it did not
> behave very well at run-time. I will have to debug it sometime. Also, it
>   would be good to have this Cygwin-specific igncr shell option enabled
> by default, so CRLF line endings are tolarated on input.

Right. That's more work than I wanted to attempt, at this point.
Personally, I wouldn't bother for a while: when we begin smoothing out
the rough patches that will be discovered in
(modularized-packages)+(mingw-get), it'd be nice if the number of
additional variables (bash-3.2, msys-1.0.dll changes, etc) were kept to
an absolute minimum during that process.

> Perhaps it would be a good idea for me to provide the MSYS runtime in
> its own package, separated from the basic support files. That way, if I
> need to update msys.bat, for instance, I do not need to upload the whole
> MSYS source code along with it.

Well, that's up to you.  Me, I wouldn't bother: I don't see it as THAT
big a problem -- with the trimmed-down msysCORE-base-src containing JUST
the msys DLL source, it's only about 2.4M.

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting Charles Wilson <cwilso11@...>:

>
> Well, that's up to you.  Me, I wouldn't bother: I don't see it as THAT
> big a problem -- with the trimmed-down msysCORE-base-src containing JUST
> the msys DLL source, it's only about 2.4M.
>

Since the individual source packages are available for download, I  
don't see any reason to include them in the MSYSCORE-base-src either.  
Instruction may need to be given to create the packaged tough.

--
Earnie




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Earnie Boyd wrote:
> Quoting Charles Wilson:
>> Well, that's up to you.  Me, I wouldn't bother: I don't see it as THAT
>> big a problem -- with the trimmed-down msysCORE-base-src containing JUST
>> the msys DLL source, it's only about 2.4M.
>>
>
> Since the individual source packages are available for download, I  
> don't see any reason to include them in the MSYSCORE-base-src either.  
> Instruction may need to be given to create the packaged tough.

I don't understand this.  msyscore-BASE-src is already stripped down to
just the msys DLL source code.  It's msyscore-1.0.11-src.tar that
contains the entire enchilada (and is really a misnomer: msys-1.0.11.exe
is the big-bundle installer, and msys"core"-1.0.11.tar.bz2 is the
big-bundle tarball -- it isn't *really* msys"CORE" at all).

As of today, /THAT/ msys"core"-1.0.11-src tarball can't be "trimmed"
anyway, because the modularized binaries' -src packages are USUALLY
different (newer) versions than the ones included in Cesar's big-bundle
msys-1.0.11[.exe|.tar.bz2] installer/tarball, for which the
msyscore-1.0.11-src tarball is supposed to provide the GPL-required sources.

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting Charles Wilson <cwilso11@...>:

> Earnie Boyd wrote:
>> Quoting Charles Wilson:
>>> Well, that's up to you.  Me, I wouldn't bother: I don't see it as THAT
>>> big a problem -- with the trimmed-down msysCORE-base-src containing JUST
>>> the msys DLL source, it's only about 2.4M.
>>>
>>
>> Since the individual source packages are available for download, I
>> don't see any reason to include them in the MSYSCORE-base-src either.
>> Instruction may need to be given to create the packaged tough.
>
> I don't understand this.  msyscore-BASE-src is already stripped down to
> just the msys DLL source code.  It's msyscore-1.0.11-src.tar that
> contains the entire enchilada (and is really a misnomer: msys-1.0.11.exe
> is the big-bundle installer, and msys"core"-1.0.11.tar.bz2 is the
> big-bundle tarball -- it isn't *really* msys"CORE" at all).
>
> As of today, /THAT/ msys"core"-1.0.11-src tarball can't be "trimmed"
> anyway, because the modularized binaries' -src packages are USUALLY
> different (newer) versions than the ones included in Cesar's big-bundle
> msys-1.0.11[.exe|.tar.bz2] installer/tarball, for which the
> msyscore-1.0.11-src tarball is supposed to provide the GPL-required sources.
>

The individual source pieces can be uploaded to the server as long as  
there is a method for putting the package together; either manual  
instruction or scripted guidance.  The individual source pieces will  
remain on the SourceForge server for as long as SF exists.  GPL  
doesn't require the source to be put in one package; just that the  
source is deliverable to the user by the same media as the binary.  It  
does require that the binary is creatable from the source in some  
fashion.  So, the msys"core"-1.0.11-src tarball could be documentation  
and/or a set of scripts for creating the msys"core" package and  
install binary.

--
Earnie


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Earnie Boyd wrote:

> The individual source pieces can be uploaded to the server as long as  
> there is a method for putting the package together; either manual  
> instruction or scripted guidance.  The individual source pieces will  
> remain on the SourceForge server for as long as SF exists.  GPL  
> doesn't require the source to be put in one package; just that the  
> source is deliverable to the user by the same media as the binary.  It  
> does require that the binary is creatable from the source in some  
> fashion.  So, the msys"core"-1.0.11-src tarball could be documentation  
> and/or a set of scripts for creating the msys"core" package and  
> install binary.

Oh, sure. But historically that's not how we've provided the -src
packages for the msys "big bundle" installers.  Changing that now is
probably kinda pointless, given that we're moving toward -- and now have
all the pieces for -- a completely modularized MSYS distribution.

IMO, the "new" msysCORE -bin package I just uploaded is already the
"least divisible unit", and the corresponding -src tarball is the
minimum source unit that would satisfy the GPL for that -bin package.

Perhaps -- if mingw-get is to be much delayed -- we could release an
MSYS-1.0.11m (for "modular") installer, which simply includes the
various modular units necessary, current as of data YYYYMMDD, for a
more-or-less equivalent installation to the existing msys-1.0.11
installer.  (But that line is really a dead end so I'd hate to waste
much time on it; mingw-get is the future).

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr