[Beowulf] hpl size problems

[Mark Hahn]

> It's interesting that you cited ATLAS as an example, BTW, because it is
> a very good one in both directions.

I certainly meant no criticism of ATLAS - it was just the example that came
to mind of a package that clearly does not provide all of a standard (LAPACK).

> What exactly is something like
> ATLAS?  It would require a lot more metadata than I think is currently
> available in order to make it packageable and distributeable in a
> plug-in fashion so that once it were installed all applications that do
> linear algebra would "just use it" where appropriate.  Some of the

precisely - my suggestion is that each interface in a standard be separately
tracked by the per-machine registry.  that means that a package needs to 
tell the registry exactly what it provides (and may conversely query the 
registry to find what it needs.)  this is not much more than a versioned,
standard-based function registry, rather than a versioned, distro-based 
package registry...

> missing metadata involves the identification of the precise architecture
> it was built for; more involves finding the right package to match the

I'm not particularly interested in different architectures, mainly because
there will shortly Be Only One.  but is it really a hard problem?  I'd think
that a single host would normally have a very limited number of arch's 
installed (normally just one, but ia32+x86-64 is not unreasonable.)
a package might offer more than one arch, but it will presumably have 
dependencies on a particular arch.

> architecture.  A third defines precisely what it can replace, and how.

but that's the whole point: a standard exists to provide a canonical
definition of the "whats".  I don't know about your "how" - if I 
install a package that replaces SUS-open-1.0-ia32 with SUS-open-1.1-ia32,
that's my choice.  a package might query the registry for the highest
version of SUS-open-*-ia32, or it might insist on 1.0.  that's up to 
the packager/author.

> I'm not certain about the fourth -- how to make "anything" that might
> use it divert calls so that they do, at least not without making it
> comply with a general ABI.

if I understand you, you're making a distinction between the version 
of a standard that a function implements, versus the version of the function.
it seems like both versions need to be kept, and that normally an app
would choose either the standard-version it's built for and the latest
function-version, or the latest of both.

> This is where I think things NEED to head.  RPM was and is in some ways
> a lovely thing.  However, I personally think it's way short on the
> metadata front, and woefully difficult to extend.  XML offers some hope
> of extendibility without requiring that the final specification be

XML is just formatting.  I don't see that it helps, since it 
doesn't do the hard part (the canonicalization - establishing the 
standard.)  using XML would be perfectly fine, of course, but the issue
(and topic!) is LSB-like efforts and how they help or miss the goal of 
permitting apps to get what they need...

regards, mark.