Re: [rpm] latest doc?

[Theodore Tso <tytso mit edu>]

On Wed, Jul 04, 2001 at 04:30:59PM -0400, R P Herrold wrote:
> 
> The LSB has curiously suggested for its standard (in its
> proposed release 1.0) that a two year old variant of the
> behaviour ducumented in an appendix to Maximum RPM, excluding
> triggers, be the 'Linux Standard'  -- It remains to see how
> this will be accepted by, say, the Debian and Slackware
> comunities..  Heck, _I_ have problems within the context of
> current RPM practice with it.
> 

The reason for this is quite simple.  First of all, it's the only
version of the RPM package format which is documented.  This is
important, since we're trying to standardize a package *format*, not
an implementation.  Not everyone is using Red Hat, after all.  A big
concern is that even though someone has carefully constructed their
application to only use LSB interfaces, and has carefully set up their
RPM spec file to only use the "lsb" dependency (to avoid the
dependency hell problem), they could still get screwed by backwards
incompatible changes caused by using a too-new version of RPM.

After all, the package might be built on an Red Hat 7.1 system, and it
might be installed on a Red Hat 6.2 system --- or on a Debian system
using the "alien" program to allow installation of RPM packages --- or
on some other distribution that is RPM based but which is using an
older version of RPM.  

So by using an old version of RPM, we lose functionality, yes --- but
we make up for it by maximizing interoperability with potentially
other systems that might not be using RPM, but simply understand how
to deal with RPM-format packages.

The other thing to keep in mind is that we're not specifying that
*all* packages in a distribution have to be packaged this way.  We're
also not saying that all LSB-compliant applications have to be
packaged using RPM, either.  (For example, Oracle will likely stick to
their own Java-based installation program to maintain consistency
across all of the OS's for which they support.)  

All we're saying is that a distibution at a minimum must support being
able to install packages which use this restricted subset of RPM.  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.

Using a Microsoft Office anology, this is basically like a company
making a policy which says that all documents interchanged within the
company must use save files in MS Word 95 format.  You can use MS
Office XP on your system, but if you're going to send a file to the
corporate internet, it must be saved in an old version of a file so
that someone running MS Office 2000 or MS Office 97 or MS Office 95
can read that file and make sense of it.  This avoids the problem
where forward incompatible changes to the document format forces
everyone to upgrade to the latest and greatest version of MS Office.

					- Ted