Features Download
From: Charles Wilson <cwilso11-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f <at> public.gmane.org>
Subject: Re: autoconf for msys
Newsgroups: gmane.comp.gnu.mingw.user
Date: Thursday 19th February 2009 15:17:08 UTC (over 9 years ago)
Earnie Boyd wrote:

> The distributed files should never contain the absolute directory, IMO.

I'm pretty sure that none of them contain *absolute* directories. They
may, however, contain usr/bin/, usr/lib/, etc, rather than bin/, lib/, etc.

>   I thought that was what we agreed to.  The tar file directories as I 
> understand we agreed to should only sub-paths that contain bin/, lib/, 
> share/, etc.  Sorry to bring up this sour point again.

When this was discussed -- a month or so AFTER I rebuilt, packaged, and
uploaded 60 or so packages for the "Real Soon Now" msys-1.0.11 release
-- I began the process of redoing all that work according to the new
recommendations.  However, I soon realized that

1) there were still some unanswered questions about the packaging and
naming formats which have YET to be answered, IIRC. (More later; it's
been so long I forgot what they were. I'll have to check my archives.)
Heck, by the time I get back to this I'll need to respin to latest
upstream anyway.

2)  and there was no [email protected]#%!%$ point, as msys-1.0.11 will
NEVER be released unless /something/ changes.  The whole msys
"distribution" is a shambles, as is mingw. There are a number of reasons
and symptoms: the unmentionable sourceforge download "system", the
inexplicable reluctance to stamp msys-1.0.11-core as "good enough and
better than 1.0.10", the fact that EVERYONE realizes the current
installer needs a major overhaul or replacement -- to the point that
there are maybe half a dozen independent replacement installers out
there. Why haven't those folks tried to fix the official one?  Oh --
some of them HAVE -- and there have been unreleased improvements in CVS
for over two years.  THAT's why they went off on their own;
contributions are, perhaps, accepted -- but then left sitting in CVS.
Who is in charge of creating a new release of the current installer? Who
is in charge of deciding -- or even calling for a consensus decision --
that it is time to scrap the existing installer and starting over, or
adopting one of the replacements already 'out there', setting a deadline
for that decision, and then implementing it?  Cygwin is not the best
example of organization, but there are two or three people with overall
authority, and every "package" in the distro has a specific, official,
maintainer (or is *explicitly* unmaintained, and available for
"adoption"). That latter bit is *really* important, and there is no such
correspondence here ("last guy to upload something wins, until somebody
else uploads a replacement"? That's not a policy, it's chaos.) [*]

In short, who is in charge?  There is a serious lack of direction in
this project -- apparently due to the fact that many of the previous
"movers and shakers" have had personal/medical issues recently. That's
understandable -- I fall into that category myself -- but doesn't change
the fact: mingw/msys is floundering.

On point: if some of "my" packages have absolute paths in them, or
include usr/bin/ rather than bin/ -- I'll fix them just as soon as I
believe its worth my time, and not before. See above for what that would

[*] non-rant: perhaps because originally the msys distribution itself
was not "packaged" -- it was monolithic, but "updates" *were* packaged.
I note that despite Keith's(?) original hope for a componentized msys
distribution, there is still a tendency towards monolithicness in the
msys"core" -- perhaps due to the desire to emphasize the "minimal"
footprint by controlling just which parts of (nominally independent
project sources) are considered part of the "minimal" set.  That is,
msys-core contains some, but not all, of coreutils (and bzip, and tar,
and patch, and...). WHY? This means if the coreutils-MSYS "full" package
is updated but msys-core is not, to get the updated tools you have to
expand your minimal distribution by installing the entire
coreutils-MSYS. (or, even worse, the msysCORE package must be updated by
some poor sap EVERY time the coreutils-msys package updated. AND every
time the patch-msys package is updated. AND every time the grep-msys
package is updated. You get the idea).

Two coupled ideas: "the new installer" should have "profiles" -- or at
least, ONE profile to which other packages can be added at the user's
option. Call this profile "base" which includes all of the
(fine-grained) packages that comprise the minimal msys installation.
Second, ensure that "the maintainer" of (e.g.) coreutils always packages
it in two (or more) pieces, where one (or more) of those sub-packages
contains just the parts of coreutils that should be in the "base"
profile, and the other (or others) contain the additional stuff. Thus,
msysCORE shouldn't really be a package, but an explicit collection of
independently updated packages that are always installed by the
installer. (This will also simplify our compliance with the GPL, as the
"source" for msysCORE...currently contains multitudes: coreutils, bzip2,
rxvt, lzma, tar, patch, texinfo, gzip, grep, diffutils, file, bash,
make(msys)...plus a few homegrown items).

To retain the ability of "old school" users to "install" the minimal set
without using the installer -- or, to begin moving to this model before
we HAVE that new installer -- simply list, on the wiki or web page,
which "packages" comprise the minimal installation -- that is, which
packages are part of the "base" profile:
   msys-core-*-bin.tar.*     (#####)
   libW11-*-dll.tar.*     (##)
   rxvt-core-*-bin.tar.*  (##)

(##) may eventually be removed from the base profile/"msysCORE" per
Keith, but it's there right now.

(#####) this has NO relation to the current msysCORE package. It simply
represents, when you compile the sources in current CVS under src/winsup
as modified from sourceware by use for msys, what you get that should be
part of the base installation. In THIS case, including the msys docu.
Any other results of that compilation should go in "msys-other" (or

Obviously, for each *-core package there'd also be additional packages
containing the "rest" of each source, "coreutils-other" (or -extra?),
"bzip-other", even "msys-other".  rxvt-core, for instance, contains the
only executable provided by the rxvt source when compiled for msys -- we
haven't ported rclock -- and libW11-*-dll contains the dll per the
packaging discussion from 18 months ago, but rxvt-other would contain
the "extraneous" stuff like documentation, man pages, etc. Those aren't
in the current "minimal" profile of msysCORE, and so couldn't be in the
(sub)package that is part of the new "base" profile.)

Great ideas, right? Put my money where my mouth is, right?


I've learned -- or been taught -- that doing so is foolish.  There's no
point until there's some decisive leadership, or formal mechanisms to
impose such via shared responsibility, like the gcc steering committee.
Otherwise, it'll be just one more "new installer" to join the rest,
sitting, waiting...for something.


Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
-OSBC tackles the biggest issue in open source: Open Sourcing the
-Strategies to boost innovation and cut costs with open source
-Receive a $600 discount off the registration fee with the source code:
MinGW-users mailing list
[email protected]

You may change your MinGW Account Options or unsubscribe at:

This list observes the Etiquette found at 
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
CD: 16ms