Re: [rpm] latest doc?

[R P Herrold <herrold owlriver com>]

On Thu, 5 Jul 2001, Theodore Tso wrote:

IANAHNBARHE -- I am not and have never been a Red Hat
employee.  The following is my take.

> 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.

Referring to the link at:
http://www.linuxbase.org/spec/gLSB/gLSB/swinstall.html

> This is
> important, since we're trying to standardize a package *format*, not
> an implementation.

hmmm?  This comes as a surprise.  The doxygen documentation of
RPM, and indeed, the extensive documentation in the rpm-devel
package far exceed that of an appendix of Maximum RPM.  As a
bonus, one gets the benefit of nearly three intervening years
of development on the product.  All GPL.

[root@couch src]# rpm -q rpm-devel ; rpm -ql  rpm-devel | \
       grep doc | wc
rpm-devel-4.0.2-8
    745     745   49280
[root@couch src]#

But to some degree this is unfair, for it is produced on an
automated basis, and somewhat unapproachable.  So see:

[root@couch man3]#  man \
     /usr/share/doc/rpm-devel-4.0.2/apidocs/man/man3/rpmlib_h.3.gz

Notice that even with the RPM v.3 package format of Maximum
RPM, there are laments of 'cruft' which are supported but need
to be excised.
   http://www.rpmdp.org/rpmbook/node119.html#SECTION031423000000000000000

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.

[ I am guessing that it describes package format 3 -- but it
MIGHT be package format 2 -- one cannot immediately tell, for
the Title page does not say -- Be right back ...  As yes, here
it is, mentioned in passing two levels down:
   http://www.rpmdp.org/rpmbook/node119.html
-- not too impressive for a proposed specification document
-- but then it was never intended to be such -- it was and is
just a secondary source, describing SOME aspects of the
package format. ]

If truly the issue is the absence of an up-to-date Appendix
style specification as referred to, let's talk ... PLEASE do
not set into stone a DOA package format statement just because
it is there.

-------------------------------------

>  Not everyone is using Red Hat, after all.

And not just Linux with .deb's and Slack-balls.  perl CPAN,
Including your truly -- but being familiar by use with the
HP-UX 'depot', the SGI packager, the Solaris pkgtool, OpenBSD
tarballs; the FreeBSD 'ports' build mechanism, ... and dare I
say it, even the MS Install-shield type tools -- In the Linux
sphere, have developed literacy with the RPM format, and have
come to prefer it, and the growth which have occurred in the
last couple of years under JBJ.

> 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.

People who read the release notes, or RTFM, or followed the
open rpm-list, were not surprised.  People who compile and
complain first receive what they have asked for and earned.

I am still running a chassis with a libc and gcc and kernel
with sources pulled from the MIT mirror, compiled on a
Slackware base with a 1.2.13 kernel as my office dialup router
-- I followed the former, elaborate instructions for
generating the libraries and compiler -- It worked, with a bit
of time and effort. Versions change -- methods for success
don't.  Read the doco, and it will build.

If the king crab is to grow, it will necessarily outgrow the
strictures of a prior exoskeleton.  LSB is describing a two
year old crab, and without a revisitation/restructure
procedure in the standard, LSB 1.0 would strangle growth.

More likely, just as the Internet is alleged to route around
impedimenta to the free flow of information, the LSB will find
ithe 1.0 proposal 'routed around' by the Debian-ites and
Slackware folk.  The Cost/Benefit ratio is not compelling.

Stuart Anderson said two years ago:

' ...but what the LSB is going to have to do is just kind of
nail things down for the common stuff in glibc and say, "Okay,
it's going to be this way and it can't change any more. If you
want to innovate you gotta find other ways of doing it."'

   http://www.owlriver.com/projects/SLUG/Anderson_SLUG_990724rev.html
at para. 4

If LSB had been effectively 'nailed down' a library standard
two years ago, we would never be able to get to kernel 2.4
series.  A year ago, and the OpenSSL libraries are not within
the scope.

The 'compatability library mess' between RH and SuSE drove me
to distraction at the end of the libc5 days when RH had phased
out further maintenance -- the pressure of the market to chase
Red Hat pulled Linux out of that mess.  Not 'you gotta find
other ways ...'

--------------------------------

Under the "screwed by backwards incompatible [RPM] changes"
line of analysis, the more reasonable choice would be seem to
be the Debian package tool system.  The advertised capability
of Debian's packager is that (at least for -latest -- clearly
the other two more current branches regularly descend into
dependency morass, just as one can with ANY packaging tool),
dependency hell has been engineered out by the release QA
process.

The problem with Debian is that the release cycle is glacial,
and does not meet commercial reality of a customer base which,
for whatever reason, insists on more curent kernels,
libraries, and packages, across the board.  The super-heated
'speed to market' mentality in the consumer market, and the
pushes on the glibc libraries and GCC by Red Hat have forced
some honesty and accountability on 'getting to released' in
the Open Source community.

There is no doubt about it -- RPM cannot stand still -- JBJ
has discussed his roadmap -- I have kibittzed, as have others.
RPM v.1 package format is gone and unlamented.  RPM v.4
package format is working well -- but I opined just a week ago
at a local usergroup that RPM was not likely to see a
.DEB-style 'Suggests:' mechanism anytime soon.  ... And in
like fashion, there is no effective 'stick' that would 'force'
the Debian camp to RPM at any level.  The fork is too far --

Perhaps RPM the program should learn to 'eat' .deb's directly.

------------------------------------

You are to some extant 'preaching to the converted' on the
concern for good documentation of RPM and its usage.  I filed
an RFE to 'lend a helping hand to newbies to RPM' at:
   http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=42473
and JBJ's response was to the effect that 'it has been a
year, we have to move forward'

And he is right from the perspective of an employee of a
publicly held company.  A professional packager who needs to
be told how spec file building works, is not yet serious about
selling to the domestic US Linux market.  And getting to that
point will imply that tarballs are working.  The shrink wrap
market is harder -- but frankly the internet as a distribution
channel has changed this.  When is the last time you bought a
non-game, non-free piece of software?

> 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.

Wrong direction arrow.  Build on a 6.0 box and it will run
forward to a 7.1 box, 30 month's coverage so far.  Build on a
5.0 box and we get 48 months.  (The only tricky part is in
PAM, when authentication enters the equation.)

And with minimal .SPEC file hygene, and a couple of macro
substitutions (well documented in the preadily available
source code with a .spec file in a .src.rpm), to catch the RH
7.x move to compliance with the Linux FHS, it is even easier
than    tar ** ./configure && make && make install  -- the
genius of RPM is that conservation of pristine sources, ALL
patches, and the .specfile 'recipe' to bake it up ...

> 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.

Frankly, a vendor who cannot get to his own answers on the use
of the current RPM need only ask; examples exist in the
archives of this list within the last two months; Free help
there -- or I'll sell packaging services, as probably will Jim
Knoble, or even (probably will) Red Hat through Jeff.  And
sign and abide a NDA as to the packaging, and probably have a
build environment in my disk image archive to permit
regression testing, which is all GPL, and for which I can
burn a testing image CD or DAT or DLT or drive image.

> 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.

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?

 Even within the strict confines of Red Hat, two databases --
rpm and rpm-lsb -- (or a -lsb tag)  will be tricky during the
transition;  IANARHE, but I'll bet Red Hat will get compliance
with a month's specfile rework on the lsb covered base
packages, and an audit tool.  Another two months for QA and
beta testing -- work the calendar, and you can tell me the
version number where LSB 1.0 'compliance' will be done from
RH's point of view.
   http://www.owlriver.com/redhat_versions.html

> We're
> also not saying that all LSB-compliant applications have to be
> packaged using RPM, either.

Heck, not even LSB's proposal is rpm-packaged complete.  A
tarball, updating an RPM !!!  How in the world can that EVER
rpm -V cleanly?  Answer:  It cannot.
    http://www.linuxbase.org/spec/gLSB/gLSB/app-b-lsb-environment.html

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 ...)

> 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.

Again, 'install' is only part of the equation,  See eg,
   http://stones.wcbe.org/~COLUG/notes/0002mtg/RPM_UG_outline.html
at section 3.

>  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.

> 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.

Not too good an example -- The CFO gets the best new computer
with the 'best' non-free oferings from everyone's favorite
monopolist -- and whips up an Access'2000 database.  Oops
-- no ability to write in a prior Access format.

... and the payroll clerk in the branch office is stuck with
her copy of O'97 -- oops -- cannot read it.

Incompatible changes happen -- managing them is important;
avoiding them is impossible, but worthwhile.  Avoiding using
the stale restricted Maximum RPM appendix format is a good
start.

> 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.

In an ideal world; in the corporate world I support, this
turns out not to be the case in practice.


By the way, thanks for posting updates to e2fsprogs at your
personal ftp site -- they saved my tail a year and a half ago
when my filesystem got wedged on my lead devel box.

Best regards,

-- Russ