Re: Autoconf and apt

[Allan Clark]

On Tue, Aug 19, 2008 at 17:37, Bob Friesenhahn <address@hidden
> wrote:

> On Tue, 19 Aug 2008, Allan Clark wrote:
>
> Heh.  Jokes aside, I figured there's a good chance that the same "project"
> (ie 
> http://freshmeat.net/projects/{PROJECT}<http://freshmeat.net/projects/%7BPROJECT%7D>or
>  http://
> {PROJECT}.sf.net/)
> provides the same deliverables cross-platform.  For example, the libz on
> Solaris, Redhat, UNIX, and BeOS probably comes from project "libz", and so
> "libz" or the URL to a libz-maintained translation (ie
> http://freshmeat.net/projects-xml/zlib/zlib.xml ):
>
> Unfortunately there are many other factors beyond where the most recent
> version of the package came from.  Often a particular version of the package
> is needed, that package needs to be built with certain other packages, and
> certain options and compilation flags need to be used.
>
> If humans have extreme difficulty understanding this stuff, it is difficult
> to imagine how it can be automated by a simple shell script.
>
> Freshmeat is a commercial enterprise which may go away tomorrow or be
> purchased by Grim Reaper, Inc., so it should not be referenced by a GNU
> tool.  The FSF maintains its own list of software so that one might be a
> better one to refer to.


I thought we were shooting for the general case, not corner-cases -- "zlib"
on most platforms tends to have the same build options, but users would
still have to hunt down "Festival with the Ogg Codex" or whatever
corner-cases and one-offs exist.  This kind of thing might actually reduce
corner-cases, if your optimism is the same flavour as mine.

Exploiting what *is* available today (ie the still-free-for-all Freshmeat)
gives a better chance of greater-than-zero functionality for these more
common cases, from which we can narrow the shorter FSF list *when* existing
capabilities disappear, a phased deliverable that offers potential for
iterative improvement.  The alternative is the all-or-nothing HURD -- which
I haven't checked on recently, but I recall it had an all-or-nothing
limitation.  I would prefer contingencies for disappearing resources rather
than the dependency on a guaranteed-forever-free resource that would need to
be improved.

Note also that I mention the possibility of a project-specific file -- see
"autoconf.xml" above.  This would be just as free as the software it
describes, but would be new work on a distributed effort to a new spec.

I therefore urge you to reconsider using existing resources for more common
cases rather than serial dependencies on new, undiscovered data and 100%
coverage which might be too difficult to reach.

Allan