Re: [rpm] latest doc?

[Theodore Tso <tytso mit edu>]

On Fri, Jul 06, 2001 at 12:08:19AM -0400, R P Herrold wrote:
>
> This has been a strong theme on JBJ's and RH's part for the
> last 18 months -- To lock into a Standard a crufty relic, and
> therefore to REQUIRE its support through backward
> compatability hooks __FOREVER__ is very hard to fathom as a
> rational act.

My understanding is that there isn't much in the way of backwards
compatibility hooks that are necessary to support older RPM packages.
It's just a matter that new RPM files have all sorts of new header
tags which older RPM's don't understand.  So basically all we're
saying here is "don't use the new-fangled tags which cause older RPM's
heartburn".

(Of course, I can't say for sure, because the new format isn't
documented *anywhere*, and Jeff has said he has no interest in
documenting it.  And I don't have time to go wading around in someone
else's C code to devine the new package format rules.  RTFM is not a
format specification.  And you really don't want to have a
specification which states, "we don't know what the pacakge format
is; but you can take a look at the source code of XXXX and that's
pretty much it.")

> Come on, get real.  As a practical matter, how can one think
> running two package versioning systems -- one Distribution
> vative, and the other LSB-specified is _simpler_ and _less_
> error prone than a unified system?

Huh?  No one's talking about running two package versioning system.
We're just talking about using a restricted subset of an RPM package,
which newer RPM's have absolutely no trouble reading! 

We're just not using any of the newer features of RPM.  For the
specific case of installing LSB applications, a lot of the newer
features are pretty much irrelevant.  We don't allow any kind of
dependencies other than "lsb", because the package naming conventions
and dependency conventions differ from distribution to distribution.  


> Why in the world would one give up the authentication and
> verification benefit of RPM voluntarily?  Why would LSB even
> suggest such a thing?  The suggestion implies a lack of
> understanding of WHY rpm works so well -- as discussed in the
> first chapter of Maximum RPM. (Hey -- I paid retail for my
> copy ...)

Because various software vendors have stated in no uncertain terms
that they weren't going to change their products to use a Linux-native
packaging scheme.  

> >  So
> > ISV's who do wish to use some kind of packaging system so that users
> > can easily update and/or delete their application using the system
> > standard packaging utilities can rely on this very basic level of
> > functionality.
> 
> But to meet this, a ISV will almost unalterably be shipping a
> slew of 'Vendor-private' dynamic libraries in lsb-rpm format:
> 
>   http://www.linuxbase.org/spec/gLSB/gLSB/app-b-lsb-compliance-example.html
> 
> Talk about the Gates of DLL Hell ... this way to the morass.

Huh?  First of all, whether or not an ISV chooses to use vendor
private dynamic libraries is completely orthoganol to whether or not
they decide to use their own custom installation tool or use an RPM.

Secondly, vendor dynamic libraries live in an application-specific
location.  They're not allowed to overwriten system libraries; so we
don't have the DLL Hell problem.


						- Ted