Updated packages available (wave 4)

[Charles Wilson-8]

I've uploaded new versions of various existing MSYS packages to
sourceforge, as well as an MSYS version of groff and man.  This update
is a little different than the previous ones; in this case I've actually
rebuilt and updated some of the components of msysCORE, rather than
restricting myself to elements of the old MSYS DTK and "Supplementary
Tools".  I wouldn't ordinarily have done that (treating msysCORE as
owned by Cesar [[I forgot, in wave 2, that bzip2 was part of msysCORE;
also wave 2's xz package obsoletes/replaces msysCORE's lzma]]), but:

  1) I actually ran in to problems with our old versions of some of the
tools, esp. sed, diffutils, and gawk, while building the other tools.

  2) By splitting these out into separate packages, future versions of
"MSYS" can simply be created as a "profile" of
which-sub-packages-to-install, in our nifty new to-be-developed
installer, rather than requiring the current monolithic
build-world-and-call-it-msyscore strategy

  3) And, some of these (rxvt) need to be removed from msysCORE anyway.

In general, I compiled each tool with languages enabled (do we really
want to take the position that non-English speakers are unwelcome, when
all it requires from us to support them is to remove "--disable-nls"
from our build scripts?  The "gettext is not part of core" argument
doesn't apply any longer, as /nothing/ will really be part of core
except msyscore-base once we have the modularized installer, and msys
gettext isn't even a shared library so there's no additional -dll
package to worry about). The impact on download size is fairly small, as
the message catalogs compress nicely; impact on installed footprint is
sometimes larger -- in several cases I packaged them in a separate -lang
tarball.  And the end user can always do "rm -rf /usr/share/locale" if
they really want to; the binaries will still work but all messages will
be in English.

Each package has been updated to the latest official upstream release,
and incorporates relevant patches from Debian, cygwin, and forward ports
of existing msys patches.  The release notes for each package indicate
test results; by and large all tests passed, or the failures were few
and acceptable (typically due to MSYS-no-symlink, and MSYS-lax-chmod-bits).

You may also notice that some of the executables are larger than
previously. This is /not/ because of the NLS support -- at least, not
directly; very little of the growth is attributable directly to libintl.
 Rather, the newer versions of many of these tools now expect to be able
to handle multibyte and/or wide character *data*, regardless of whether
their own messages are translated or not.  However, given the lack of
support for multibyte and widechar in MSYS itself, the GNULIB
replacement functions are triggered. Since GNULIB replacement functions
are linked in statically -- the binaries get bigger.

There are only two cures for this:
  1) stay with old versions of the tools, which do not expect nor
include GNULIB replacements for multibyte and widechar text handling
  2) Update MSYS (v2.0?) to provide this support intrinsically, like
cygwin-1.7 does


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

MSYS CORE components
   MSYS sed           3.02   -> 4.2.1
   MSYS m4            1.4.7  -> 1.4.13
   MSYS file          4.16   -> 5.03
   MSYS grep          2.4.2  -> 2.5.4
   MSYS gzip          1.2.4a -> 1.3.12
   MSYS gawk          3.1.5  -> 3.1.7
   MSYS texinfo       4.11   -> 4.13a
   MSYS less          358    -> 436
   MSYS tar           1.19.90-> 1.22
   MSYS diffutils [*] 2.8.7  -> 2.8.7.20071206cvs
   MSYS patch         2.5.4  -> 2.5.9
   MSYS findutils     4.3.0  -> 4.4.2
   MSYS rxvt     [**] 2.7.2  -> 2.7.10.20050409

MSYS DTK Components:
   MSYS mktemp  [***]     1.5 -> 1.6
   MSYS cvs           1.11.22 -> 1.12.13
   MSYS vim           7.1(285)-> 7.2(245)

NEW:
   MSYS groff   [****] 1.20.1
   MSYS man     [****] 1.6f

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: if it has "-dll" in the name, you'll probably need it at
some point, so download and install all of those.  You'll definitely
want mktemp-bin (it should have been added to msysCORE-1.0.11, but was
missed).  After that, you probably want the various -bin packages in the
MSYS CORE group, to update exising tools.

Finally, whether you install cvs-bin, vim-bin, groff-bin, and man-bin is
up to you.  As always, *-msys-*-dev packages are of interest only to
those developing MSYS applications using the MSYS DVLPR environment.

[*] Needed to use CVS because otherwise autoreconf failed. The reason
for choosing 20071206 instead of HEAD was because that's the CVS version
that OpenSUSE is using, and has tested -- no sense in us being the
guinea pigs for any additional changes (although there aren't that many
commits after that date).

[**] Updated to current cygwin release. Upstream development has
stalled, as of 20050409; these sources represent the latest CVS version
available from sourceforge, as well as incorporating additional changes
from cygwin.

[***] mktemp is provided as a standalone package. However, it was added
to coreutils as of version 6.10 (22-Jan-2008).  If we ever update
coreutils beyond 6.0, that'll require some coordination.

[****] I got tired of having to fire up cygwin to run man, and I've
never had too much luck with the mingw version.  However, if a user has
installed both the mingw and msys versions, obviously the $PATH settings
to prefer /mingw/bin will cause that user to also continue to use the
mingw man.  Modeling after Debian's groff-base packaging, I've split
groff-bin into two pieces: -bin is what you need for man to work. -ext
and -smp contain all the other junk and examples.


So, what's next?

For the repackaged DTK, not much:
  gmp
  guile
  autogen
  lpr

For msysCORE, there's really just
  [1] bash
  [2] coreutils
  [3] make  [cs/cp/ci?]
  [4] and, of course, msyscore-base

[2] probably should be split into -bin and -ext, where -ext contains all
the tools that AREN'T currently part of msysCORE (and -doc, -lic, and
-src, as usual).

[3] I guess we've settled on cpmake as THE msys 'make', right?

[4] This would just be what you get from building and installing msysrt,
plus the various addon scripts, icons, and whatnot.

However, I'm not going to touch any of that [1-4].  After I finish
gmp/guile/autogen/lpr, I'm done for a while.  A long while. <g>

Aside: you know, I think what we're gradually doing -- once we have the
new installer -- is similar to what cygwin did when they transitioned
from B20.1's "full.exe" to the 1.1.0 "Net Release"...

--
Chuck

P.S. Here's the list:

sed-4.2.1-1-msys-1.0.11-bin.tar.lzma
sed-4.2.1-1-msys-1.0.11-doc.tar.lzma
sed-4.2.1-1-msys-1.0.11-lic.tar.lzma
sed-4.2.1-1-msys-1.0.11-src.tar.lzma

m4-1.4.13-1-msys-1.0.11-bin.tar.lzma
m4-1.4.13-1-msys-1.0.11-doc.tar.lzma
m4-1.4.13-1-msys-1.0.11-lic.tar.lzma
m4-1.4.13-1-msys-1.0.11-src.tar.lzma

mktemp-1.6-1-msys-1.0.11-bin.tar.lzma
mktemp-1.6-1-msys-1.0.11-doc.tar.lzma
mktemp-1.6-1-msys-1.0.11-lic.tar.lzma
mktemp-1.6-1-msys-1.0.11-src.tar.lzma

file-5.03-1-msys-1.0.11-bin.tar.lzma
file-5.03-1-msys-1.0.11-doc.tar.lzma
file-5.03-1-msys-1.0.11-lic.tar.lzma
file-5.03-1-msys-1.0.11-src.tar.lzma
libmagic-5.03-1-msys-1.0.11-dev.tar.lzma
libmagic-5.03-1-msys-1.0.11-dll-1.tar.lzma

grep-2.5.4-1-msys-1.0.11-bin.tar.lzma
grep-2.5.4-1-msys-1.0.11-doc.tar.lzma
grep-2.5.4-1-msys-1.0.11-lic.tar.lzma
grep-2.5.4-1-msys-1.0.11-src.tar.lzma

gzip-1.3.12-1-msys-1.0.11-bin.tar.lzma
gzip-1.3.12-1-msys-1.0.11-doc.tar.lzma
gzip-1.3.12-1-msys-1.0.11-lic.tar.lzma
gzip-1.3.12-1-msys-1.0.11-src.tar.lzma

gawk-3.1.7-1-msys-1.0.11-bin.tar.lzma
gawk-3.1.7-1-msys-1.0.11-doc.tar.lzma
gawk-3.1.7-1-msys-1.0.11-lic.tar.lzma
gawk-3.1.7-1-msys-1.0.11-src.tar.lzma

texinfo-4.13a-1-msys-1.0.11-bin.tar.lzma
texinfo-4.13a-1-msys-1.0.11-doc.tar.lzma
texinfo-4.13a-1-msys-1.0.11-lic.tar.lzma
texinfo-4.13a-1-msys-1.0.11-src.tar.lzma

less-436-1-msys-1.0.11-bin.tar.lzma
less-436-1-msys-1.0.11-doc.tar.lzma
less-436-1-msys-1.0.11-lic.tar.lzma
less-436-1-msys-1.0.11-src.tar.lzma

rxvt-2.7.10.20050409-1-msys-1.0.11-bin.tar.lzma
rxvt-2.7.10.20050409-1-msys-1.0.11-doc.tar.lzma
rxvt-2.7.10.20050409-1-msys-1.0.11-lic.tar.lzma
rxvt-2.7.10.20050409-1-msys-1.0.11-src.tar.lzma

tar-1.22-1-msys-1.0.11-bin.tar.lzma
tar-1.22-1-msys-1.0.11-doc.tar.lzma
tar-1.22-1-msys-1.0.11-ext.tar.lzma
tar-1.22-1-msys-1.0.11-lic.tar.lzma
tar-1.22-1-msys-1.0.11-src.tar.lzma

diffutils-2.8.7.20071206cvs-2-msys-1.0.11-bin.tar.lzma
diffutils-2.8.7.20071206cvs-2-msys-1.0.11-doc.tar.lzma
diffutils-2.8.7.20071206cvs-2-msys-1.0.11-lic.tar.lzma
diffutils-2.8.7.20071206cvs-2-msys-1.0.11-src.tar.lzma

patch-2.5.9-1-msys-1.0.11-bin.tar.lzma
patch-2.5.9-1-msys-1.0.11-doc.tar.lzma
patch-2.5.9-1-msys-1.0.11-lic.tar.lzma
patch-2.5.9-1-msys-1.0.11-src.tar.lzma

findutils-4.4.2-1-msys-1.0.11-bin.tar.lzma
findutils-4.4.2-1-msys-1.0.11-doc.tar.lzma
findutils-4.4.2-1-msys-1.0.11-lic.tar.lzma
findutils-4.4.2-1-msys-1.0.11-src.tar.lzma
locate-4.4.2-1-msys-1.0.11-bin.tar.lzma

cvs-1.12.13-1-msys-1.0.11-bin.tar.lzma
cvs-1.12.13-1-msys-1.0.11-doc.tar.lzma
cvs-1.12.13-1-msys-1.0.11-lic.tar.lzma
cvs-1.12.13-1-msys-1.0.11-src.tar.lzma

vim-7.2-1-msys-1.0.11-bin.tar.lzma
vim-7.2-1-msys-1.0.11-doc.tar.lzma
vim-7.2-1-msys-1.0.11-lang.tar.lzma
vim-7.2-1-msys-1.0.11-lic.tar.lzma
vim-7.2-1-msys-1.0.11-src.tar.lzma

groff-1.20.1-1-msys-1.0.11-bin.tar.lzma
groff-1.20.1-1-msys-1.0.11-doc.tar.lzma
groff-1.20.1-1-msys-1.0.11-ext.tar.lzma
groff-1.20.1-1-msys-1.0.11-lic.tar.lzma
groff-1.20.1-1-msys-1.0.11-smp.tar.lzma
groff-1.20.1-1-msys-1.0.11-src.tar.lzma

man-1.6f-1-msys-1.0.11-bin.tar.lzma
man-1.6f-1-msys-1.0.11-doc.tar.lzma
man-1.6f-1-msys-1.0.11-lang.tar.lzma
man-1.6f-1-msys-1.0.11-lic.tar.lzma
man-1.6f-1-msys-1.0.11-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

[Cesar Strauss-2]

Charles Wilson wrote:
> I've uploaded new versions of various existing MSYS packages to
> sourceforge,

Great!

> as well as an MSYS version of groff and man.  This update
> is a little different than the previous ones; in this case I've actually
> rebuilt and updated some of the components of msysCORE, rather than
> restricting myself to elements of the old MSYS DTK and "Supplementary
> Tools".  I wouldn't ordinarily have done that (treating msysCORE as
> owned by Cesar [[I forgot, in wave 2, that bzip2 was part of msysCORE;
> also wave 2's xz package obsoletes/replaces msysCORE's lzma]]), but:

I do not mind at all. Good help is always appreciated.

>   2) By splitting these out into separate packages, future versions of
> "MSYS" can simply be created as a "profile" of
> which-sub-packages-to-install, in our nifty new to-be-developed
> installer, rather than requiring the current monolithic
> build-world-and-call-it-msyscore strategy

Agreed. It is much easier to incrementally update individual packages
this way.

> For msysCORE, there's really just
>   [1] bash
>   [2] coreutils
>   [3] make  [cs/cp/ci?]
>   [4] and, of course, msyscore-base

I think I can take care of them. It is the least I can do ...

> [3] I guess we've settled on cpmake as THE msys 'make', right?

Yes, I think so. I am glad we eventually found a compromise.

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:
> Charles Wilson wrote:
>> I wouldn't ordinarily have done that (treating msysCORE as
>> owned by Cesar [[I forgot, in wave 2, that bzip2 was part of msysCORE;
>> also wave 2's xz package obsoletes/replaces msysCORE's lzma]]), but:
>
> I do not mind at all. Good help is always appreciated.

Good to know I haven't stepped on any toes (well, except for Keith's
mild annoyance with groff/man).

>>   2) By splitting these out into separate packages,
> Agreed. It is much easier to incrementally update individual packages
> this way.

Yep.  The downside is, with a componentized distribution there is no
longer any intrinsic relationship between the entire set of applications
installed, and the "version of MSYS you are using".  (We get this on the
cygwin list a lot: "I'm using cygwin version 1.5.25-15, and sed doesn't
work...")

However, I imagine that the new installer (mingw-get?) will also
maintain a database of installed packages and their versions, and then
we could develop a simple tool (script?) to extract that data, similar
to 'cygcheck -cd' on cygwin.

Cygwin decided against the following, but MSYS could choose to do so:
the "profile" for MSYS-BASE (or MSYS-DTK) could be version-specific.
That is:

MSYS-BASE-2.0 contains
    msysCore-1.0.11-1-bin (and -lic)
    bash-3.05-1-bin (and -lic)
    sed-4.3.1-1-bin (and -lic)
    coreutils-5.97-3-bin (and -lic but not -ext)
    etc

Such that each "official" MSYS-BASE release contains exactly certain
versions of the various constituents.  Cygwin's "base profile", instead,
just specifies "the latest" vesion of the whatever constituents are
considered "core", and the time of installation.  In MSYS terms:

MSYS-BASE-2.0 contains
    msysCore-bin (and -lic)     [no version specified]
    bash-bin (and -lic)         [no version specified]
    sed-bin (and -lic)          [no version specified]
    coreutils-bin (and -lic but not -ext) [ditto]
    etc

Note that in this case, the components listed as 'requirements' of
"MSYS-BASE-2.0" aren't actually "package names" that satisfy the schema.
Implicitly, they should just match "whatever is the current (latest)
version on sourceforge".

>> For msysCORE, there's really just
>>   [1] bash
>>   [2] coreutils
>>   [3] make  [cs/cp/ci?]
>>   [4] and, of course, msyscore-base
>
> I think I can take care of them. It is the least I can do ...

Great!  If you review my original postings a few months ago, I first
proposed the specific package names and content breakdown, before
(wasting additional time) re-re-re-re-re-uploading each revised version.
It's only lately, once we all nailed down the naming scheme and the
more-or-less "normal" way that packages should be subdivided, that I
started uploading without a preliminary "hey, what about this?" email.

You might want to revert to the earlier mode (propose before uploading),
just to avoid rework, if any might be required.

BTW, I will soon be starting another thread concerning the lpr tool,
which may affect msysCORE, so stay tuned.

--
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

[keithmarshall]

On Thursday 27 August 2009 17:58:30 Charles Wilson wrote:
> BTW, I will soon be starting another thread concerning the lpr
> tool, which may affect msysCORE, so stay tuned.

Isn't that lpr "tool" just the Q&D script I provided a few years ago,
to stream file data out to a Windows print spool?  It has served me
well for years, but I only published it because someone on the groff
list asked if anyone knew a way to do just that.

IIRC, it works for either MSYS or Cygwin.  I based it's configuration
on an LPD/LPR model, because that was convenient for letting me push
plain text files, or groff's PostScript output to a single physical
HP PCL-5 printer, while allowing that one device to simulate several
logical printers, with a variety of character pitches and page
orientations, without me having to jump through hoops every time I
wanted a different layout.

Do we actually need anything more sophisticated?

--

Regards,
Keith.

------------------------------------------------------------------------------
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