Re: protocol idea - could change things considerably :)

[Paul Jarc]

Dan Stromberg <strombrg@dcs.nac.uci.edu> wrote:
> How can an automatic build system automatically
> determine what is the latest version of a software package, where to find
> it, how to download it, how to build it, and what is its relationship to
> other pieces of software?

This sounds more like a package manager than a build system.  To my
mind, a "build system" is more like make, autoconf, etc. - it's what
the package author chooses to manage compilation.

Some of what you want is handled in the slashpackage system with my
sptools programs:
<URL:http://cr.yp.to/slashpackage.html>
<URL:http://multivac.cwru.edu./sptools/>

You might also be interested in sp-foreign, which is undergoing some
redesign work right now.  Since I have more sweeping control over the
per-package metadata here, I've been able to do more - e.g., tracking
dependencies.
<URL:http://multivac.cwru.edu./spf/>

> This software system could be layered overtop of .tar.Z, .tar.gz,
> .tar.bz2, .rpm, .deb, sun pkg's, AIX lpp's, .srpm, and so on.

Some of this information is already stored *inside* rpms, debs, etc.
For information that can't be known when the package is created, the
package can contain a URL where the latest information can be found.
(That's how sptools finds the latest version.)

> screen scraping as much of this information as possible from HTML,
> or doing directory listings of ftp sites.

I wouldn't be very confident of getting accurate information that way,
since it isn't intended to be machine-readable.

> For example, if "conflict" were described by a percentage, that
> would produce a more flexible system

I'm not sure how that would be meaningful.  But then, I don't much
like the idea of conflicts in packaging systems anyway.  The package
maintainer doesn't know how I intend to use the package, and so can't
reliably predict what would conflict with that intention.

> If I may be extremely immodest for a while, I'll mention that I believe
> that this could change the free software, -and- lock-in software worlds
> substantially, and as such, is suitable for a patent application.

Those qualities aren't what makes an idea suitable for a patent.
Novelty is required, and there is prior art here.

> I have little interest in restricting access to such a general method, nor
> in making minibucks from it (sic), when I believe this could be a "rising
> tide lifts all boats" kind of thing for the software industry.

Good.  One of the ideas that has been suggested for making something
unpatentable is to apply for a patent, and then neglect to pay the
final required fee.  That puts the application in the patent office's
database, to ensure that no one else would be able to patent it, but
still leaves it available for anyone to use.


paul