Re: individual software releases for third parties

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> http://ftp.rodents-montreal.org/mouse/blah/2009-11-20-1.html for
>> those who are interested.

> Funny how you start with pkg-config, which is an unnecessary
> invention given the existence of autotools - the philosophy of
> autotools being to test for features, not look for version numbers.

*shrug*  I don't recall what it was that demanded pkg-config, but
something did, and while trying to install it I had its configure
script explode as described.  Saying that the "what it was" shouldn't
use pkg-config to start with, even if true, is irrelevant to the point
about configure scripts not doing what they're supposed to.  (I don't
recall whether the thing that wanted pkg-config had its own configure
script or not; it might not have been using the configure paradigm.)

> Then you go on to statfs - is the solution in
>     https://bugzilla.gnome.org/show_bug.cgi?id=617949
> OK?

I don't know; I neither have nor want HTTPS support, and when I try
http:, it isn't willing to give me anything but a redirect to https:.
Nor do I particularly care; whatever desire it was that wound up with
my trying to install glib has long since been addressed some other way.
(That blah post dates from November 2009.)

The point is not to fix these particular examples.  The point is that
configure scripts have, shall we say, a rather poor track record for
me.

I don't use one of the popular alternatives - OSX, a big Linux distro.
That doesn't matter; the whole point of configure scripts is to adapt
to whtaever idiosyncracies the system exhibits, and in my experience
they're running at about 1/6 on that.  (The ones in the blah post are
just the ones that failed so hard configure didn't even run.)
Specifically....

There are a handful of other programs which were useful enough I was
willing to go through the work to vet the configure script to my
satisfaction; I just counted on the system at readiest hand, and I find
seven of them.  Looking at my build scripts for them, only one of them
works smoothly.  Two others I install manually; either the configure
script couldn't be made to install them properly or it looked like more
work to make it do so than to install manually.  Three of them I have
patches I apply post-configure, though in one case it's just to fix the
install mechanisms.

So, really, the count is more like, out of 11 programs,

- Four explode so badly configure doesn't even run.

- Two need post-configure patches to repair non-installation damage
   done by configure.

- Three need manual help to install.  (I'm not even counting having to
   run configure with a multi-hundred-character command line.  It is
   possible that configure could be coaxed into working in one or more
   of these cases, but when getting the "just do it" script to work is
   more work than doing it manually, the script has failed at its job.)

- Two, at most, work smoothly.  (As far as configure goes.  Even these
   programs need patches, but I'm not counting pre-configure patches,
   since in most cases they're dealing with issues in the software
   proper rather than its configuration mechanism; I haven't, however,
   gone through the relevant patches in enough detail to be sure.)

Two out of eleven worked as advertised.  If you don't count
installation trouble, five out of eleven.  Even being liberal enough to
demand only that the configure script _run_, not that it actually
_work_, brings it up to only seven out of eleven.

This is an *atrocious* record, especially for something that's supposed
to _ease_ software installation.

It's possible the other nine - or six - are due to improper use of the
tools.  But when a tool has a record this bad, it's difficult to avoid
blaming the tool at least partially, and it most certainly is valid to
treat it as a strong correlate of "this is likely to be a major
headache to install".

And then there are the other issues my blah post raised with the
./configure paradigm, which you didn't address at all.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B