Application certification (was Re: [Beowulf] hpl size problems)

[Mark Hahn]

> >>related to Red Hat.  The first of which is that the LSB mandates the
> >>availability of RPM as a packaging method.  This isn't so bad, except that the
> > 
> > 
> > I don't see what the problem is - RPM is expressive enough, probably.
> > look at Yum - probably one of the best package tools, and not apparently
> > crippled by RPM.
> 
> The problem is that yum still uses RPM under the hood.  Why should my prefered 
> Linux distribution be a second-class citizen because it has its own mechanism 
> for resolving dependencies that Red Hat hasn't blessed?

I'm assuming that your distro is not using its format purely for turf
reasons.  so the question in: what does it do that RPM doesn't?
packaging/dependencies is not rocket science, even at the scale of distros
(which all differ mostly in desktop deco schemes.)

> > really?  I haven't looked at a lot of binary/closed apps, but what do 
> > they depend on?  LSB covers all the normal system interfaces, including X.
> 
> Lets start with toolkits on top of X, such as motif, gtk, or qt.  Or, to use a 
>   library close to RGB's heart, libxml2. For that matter, any of the standard 
> numerical libraries that many of us live by, such as blas or lapack.

all you are saying is that LSB should be extended; OK, why don't you and
other users (or perhaps distro-vendors, or even (gasp) app vendors) simply
work with LSB to do this?  again, what is the impediment?  I can't imagine 
that there are any issues with the GUI toolkits except perhaps settling on 
a version.  with blas/lapack, there are some minor issues (MKL, ACML, ATLAS,
Goto, netlib-lapack?)

> >>used libraries, or use RPM dependencies to require other packages to be
> >>installed.  The latter option is the path of least resistance, especially if a
> >>suitable RPM can be installed from the Red Hat installation media.  Even if such
> > 
> > but isn't that fair?
> 
> No, it isn't fair.  Depending on the Red Hat RPMs means that it isn't running 
> on Linux, it is running on one particular (very commericalized) version of 
> Linux.

I'm confused.  I thought you said that your desired app depends on a package 
which is not in your distro, but is included in RH.  why can you not simply
install the depended-on package from some RH mirror and get on with the app?
is it just the insistence on eliminating RPM-compatibility from you system/distro?

> > hmm, I use Yum, which appears to be exactly the sort of non-RPM tool that 
> > LSB explicitly permits.  it seems to do OK with non-Redhat RPMs.
> 
> But it still expects you to be storing all your package dependencies in a RPM 
> formated DB. And you still are using RPMs for your package management.  Some 
> of us do use distributions that aren't RPM based.

and so the question becomes: what advantage does your non-RPM format confer
(and if it's a proper superset, why can't it simply spew the headers that yum wants?)

> had to be expressed in Hexidecimal.  And don't market your standard to ISVs as 
> "the one way" to ensure cross-distribution compatability when it includes 
> requirements that exclude some distributions from full participation.

we all mourn the fact that standards tend to lag.  but how does this
eliminate the need for a standard?  if you don't want "the one way",
what is "the other way"?  it's obviously a non-starter for app vendors 
to test against every known distro, which is the whole motivation for 
a standard in the first place.

> Actually, I see it as rather sad.  As it was pointed out in a parallel thread, 
> Gaussian will refuse to support your installation if you are using anything 
> more recent than RedHat 9 and even them, you aren't supposed to put security 
> patches on.

the result is that no one bothers asking Gaussian for support.  or if they
really have a burning bug, they just reproduce it on an annointed machine.

> To too many ISVs Linux := some version of RedHat.  I will admit 

<shrug>.  I have no preference for RH, but nothing about it is bad enough
to make be bother not using it (FC actually).

> that I am somewhat of a Gentoo partisian, and that makes me suspect.  But why 
> should I be expected to mirror my dependency trees into an alien db format and 

turn that question around: what's so great about your native dep format?
better yet, if this is such a contentious issue, why hasn't someone developed
a "system capability manifest" format, which is package-independent, and 
everyone can use.  after all, the app just wants to know (eg) whether glibc of 
appropriate revision is installed.  it doesn't care whether it got there via
RPM or stork.

I think it would be quite good to decouple package names from capabilities
(which RH appears to be doing somewhat, since you can switch from sendmail
to postfix without un/re-installing packages dependent on the existence of 
some/any MTA.)  since people have this emotional attachment to package 
formats, the capability-name-registry should be usable by any package-system,
but not strictly a part of any of them.  this implies that someone needs to 
be authoritative about capability names when, as with sendmail/postfix,
the capability is not identical to the package revision (the way it is with
glibc).  gosh, look, that's the raison d'etre for LSB!  if only people would 
work on the LSB project rather than jeering at the LSB people (and/or
shortcomings).

> support "standard" code?   Red Hat does not own Linux, even though 9 out of 10 
> CIOs would be hard pressed to name another distribution.  The whole point of 

hmm, argument-from-ignorance, sort of a negative variant of
appeal-to-authority ;)  seriously, no one said RH owned Linux.
the fact that LSB chose RPM as the format does NOT imply that, either.

and I believe that if people went to LSB and explained why RPM is a bad
choice, it would be changed.  "but we have this other format" is not a good reason.