[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Autoconf and apt
From: |
Allan Clark |
Subject: |
Re: Autoconf and apt |
Date: |
Tue, 19 Aug 2008 17:53:46 -0400 |
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
- Re: Autoconf and apt, (continued)
- Re: Autoconf and apt, Brian Dessent, 2008/08/19
- Re: Autoconf and apt, Tim Post, 2008/08/19
- Re: Autoconf and apt, Erik de Castro Lopo, 2008/08/19
- Re: Autoconf and apt, Allan Clark, 2008/08/19
- Re: Autoconf and apt, Erik de Castro Lopo, 2008/08/19
- Re: Autoconf and apt, Ralf Wildenhues, 2008/08/19
- Re: Autoconf and apt, Bob Friesenhahn, 2008/08/19
- Re: Autoconf and apt, Ralf Wildenhues, 2008/08/19
- Re: Autoconf and apt, Allan Clark, 2008/08/19
- Re: Autoconf and apt, Bob Friesenhahn, 2008/08/19
- Re: Autoconf and apt,
Allan Clark <=
- Re: Autoconf and apt, Bob Friesenhahn, 2008/08/19
- Re: Autoconf and apt, Braden McDaniel, 2008/08/19
- Re: Autoconf and apt, Tim Post, 2008/08/19
Re: Autoconf and apt, Ben Pfaff, 2008/08/19