[linux-elitists] [rgb@phy.duke.edu: Re: [Beowulf] hpl size problems]

Greg Folkert greg@gregfolkert.net
Tue Oct 11 13:17:02 PDT 2005

On Tue, 2005-10-04 at 15:37 +0200, Eugen Leitl wrote:
> ----- Forwarded message from "Robert G. Brown" <rgb@phy.duke.edu> -----
> From: "Robert G. Brown" <rgb@phy.duke.edu>
> Date: Tue, 04 Oct 2005 09:26:29 -0400
> To: Chris Samuel <csamuel@vpac.org>
> Cc: beowulf@beowulf.org
> Subject: Re: [Beowulf] hpl size problems
> X-Mailer: http://www.courier-mta.org/cone/
> Chris Samuel writes:
> >On Sun, 2 Oct 2005 05:38 am, Robert G. Brown wrote:
> >
> >>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.
> >
> >Would Debian's .deb format be better ?
> >
> >They created it in 95 to be a more extensible version of whatever dpkg used
> >before..
> I don't THINK that the issue is one of format per se.  All packaging
> formats consist of a container with an installable tree, the ability to
> run scripts pre and post (un)install, and a variety of metadata
> associated with the packaged material -- dependencies, provides,
> information/synopsis, copyright/license information, in addition to
> package name and revision and build/release info.  The "problems" I
> allude to are in both the metadata and the associated db for storing it,
> not in the containerizing of the data in the physical file format.  One
> can make a "package" out of a simple tarball (as slackware has long
> done) instead of a CPIO archive and it would work just as well.

Oh boy. Not another RPM vs DEB deba[te|cle]. It has never been about the
format. The real reason Debian is the way it is:

	Serious POLICY and ADHERENCE to it

Simply put, this makes the format really immaterial. It you put the
policy in place even tarball packages would be awesome.

> I happen to think that the metadata in the package itself should be in
> xml format as a "meta" design choice for a variety of reasons, but even
> this isn't a necessary thing, only desireable -- it just forces you to
> structure your data in a strictly hierarchical and extensible manner,
> which I personally think is a good thing that enables much future
> development flexibility so that the metadata never AGAIN can be said to
> be inadequate longer than it takes to define and insert a new tag
> hierarchy in the appropriate place in the tag tree.

Yeap, hows that any different from any other format? Really truly, you
could do that now with rpm or deb. It is a matter of getting others to
acknowledge that changes are relevant and worth keeping up. Does this
mean we have 7^259 different schema to manage then?

> Now, there is a group working on this, and they're neither ignorant nor
> ill-intentioned.  In fact, they're pretty serious coders, as you might
> expect with such a complex and powerful toolset.  It's just that package
> management is a difficult problem and conservative development is
> ABSOLUTELY NECESSARY to avoid breaking things.  Remember what a pain it
> was in the rpm 4.x transition, where man rpms no longer built unless you
> worked on them pretty extensively. It is further complicated by the fact
> that there has recently been a (long necessary) fork between "community"
> RPM package management and "Redhat Package Management" where the two are
> in the future not necessarily going to be mutually compatible.  This
> helps address concerns voiced in this thread that Redhat will unfairly
> dominate the packaging system and be able to (whether or not they
> actually do) manipulate it to their advantage.

Yeap, just like anything else commercial.

> You can check out (e.g.)
>  https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

Still, Policy is just as an important as to flexibility. As we well know
"one size fits all" flexibility sometimes makes a bad thing. Think
really hard about spandex pants on Heather Locklear and then on Kathy
Kinney (Mimi Bobeck of the Drew Carey show)

        http://www.imdb.com/name/nm0455745/ for her imdb page. No photo
        though. GIYF.

> This is an important point.  There has been considerable discussion that
> I've listened in on from time to time about whether rpms really ARE
> inadequate in any fundamental sense, or if the problems are really just
> in the upper level tools that turn the basic rpm library calls into
> userspace or rootspace functionality.  Yum is an important case in
> point.  Who would have imagined, before the yup project, that it was
> possible to get so MUCH out of rpms, but now we all don't even think
> about it -- missing pvm on a system?  "yum -y install \*pvm\*" and a
> minute later you aren't.  Looking for a file or package?  yum provides,
> yum list.  Interested in just browsing everything available to BE
> installed?  yum info.  And rpms ARE changing.  Look at the comps lists,
> now in xml.  Also, there is effort to actually communicate with and
> debian developers and keepers of the holy deb -- there may even be
> motion of sorts to a truly universal packaging specification (since as I
> said, ALL packaging systems CAN do what needs to be done, it is just a
> matter of merging specific advantages of any of the subspecies into a
> new beast that has it all and does it all, efficiently).

It is not really about packaging specification, more and more it is
policy and keeping to that policy.

> "Real" tools like yum define the problems to be solved much better so
> that the developers don't have to head out into the wild cracked yonder
> and break a VERY VERY FUNDAMENTAL tool trying to extend it in
> ill-directed ways.  Since yum/createrepo pulls all the header metadata
> from the rpms it services, it focusses a lot of attention on just what
> is IN that metadata and just how it CAN be efficiently and portably
> represented.  This in turn can help support the kind of registry that
> Mark has alluded to, perhaps even the ability to "layer" rpm db's the
> same way that yum layers rpm repos.  The one tool defines usage, which
> provides a natural guidance track for the evolution of the underlying
> library (as well as several possible hacks that will let you do what you
> want along the way WITHOUT altering the underlying library).

Policy, the metadata format doesn't matter, the CPIO/TAR/AR format
doesn't really matter, the pre and post scripts don't matter... if you
don't have strict/very good compliance with a pre-established policy.
Policy for how the packages are to be laid out, how they are supposed to
be split (redundant across platforms supported), changelogs, signing,
submission to the archives... etc, it won't matter what specs you use.

>There are usually many ways of doing nearly anything -- the trick is in
> recognizing the one that is the least crack-ridden and that efficiently
> solves the problem and that is under your control.  Sometimes, rarely,
> all three happen to occur in concert and things bop right along and
> miracles happen.

Mkay, so we are really wanting to make sure we have a package manager
that handles everything without busting a gut. Or frying your "already
installed" status file or db or what have you. Have you looked at the
dpkg status file or the available file? Could we recover from a self
inflicted wound of removing all the metadata records be it a flatfile,
bsdDB, xml or what have you?

I know I can with Debian. As a matter of fact I have done it, the
whole /var filesystem was formatted by me on a Debian machine. I did do
the good thing and did a tarball backup of the whole fs. Silly me, I
thought I did. Oops.

This is important, the machine was still alive at that point, I just
needed to piece back everything I lost. I did and the machine ran for ~3
years until hardware failure took it at a young age.

> Finally, one MUST NOT FORGET that rpms tend to be FUBAR not because of
> any particular weakness in rpm (the design) per se or in rpmbuild, but
> out of egregious user error.  rpms with circular dependency loops, nasty
> obsoletes behavior, wider dependency chains than strictly necessary,
> overly specific package requirements (perl version EQUAL to
> blankety-blank-blank oh my holy lord -- as if you're never permitted to
> update perl if you wish to run this particular generic-perl application,
> library version EQUAL to whatever ditto), installation locations that
> are not compliant with the FHS or rpm rules and customs (rpm's that
> install man pages in /usr/man or /usr/local/man, for example, where the
> latter is "permitted" by the FHS but deprecated for rpm-based installs
> in general as packaging something de facto makes it "part of the
> distribution" by extension and hence installable in /usr).

Here again. Policy. Proper policy and actually *using* that policy to
get everything right is of utmost import. If everyone that made packages
did it the same way, but packaged them with RPM or Tar or AR (to each
their liking) this would be a moot point. Due to the fact you have any
format properly installing the package in the same FHS/LSB compliant
locations and having enforced policy to make sure this happens... makes
all the circular deps and/or version specific deps nearly disappear.

> There is no abuse under the sun that developers are not capable of,
> especially developers that e.g. work on a debian system and provide a
> spec file of sorts from some template they borrowed somewhere or
> generated by a tool that will "work" to make an rpm from their sources
> on at least some rpm-based distros at least some of the time. Not to
> pick on debian developers -- you see the same thing in rpms built by
> people who work on rpm-based system, by people who should know better,
> by people who DO know better but don't care enough to do it "right"
> because it would involve porting their code from where it built just
> fine back when you could still do it with rpm directly, not using
> rpmbuild, and why should they change?

Abuses are once again quelled by Policy. Using that policy to reject
those packages for distribution and giving specific reasons as to why...
oh hey wait, Debian has Build Daemons for just this type of thing. And
it should compile properly on all 11 archs (atm that is). How can you
tell me that some template that works somewhere or sometimes but not

Every(well almost every) package going into stable Debian releases need
to be auto-built by the Buildd daemons for each processor type. This
means that Debian Sarge with its 14,000+ packages has had to auto-build
these packages for every arch the program supports (yes I know some of
the older and less used arches don't have 14,000+ packages, but I

You aren't picking on Debian Developers, when you say/show these kinds
of things, you are ostracizing yourself. It means that, should you
decide to use the Debian repository for you core stuff, you will have to
abide by the rules set forth (policy here it is again) 

> This latter category includes a whole lot of commercial software and
> (unfortunatly!) HPC tools.  How in the world can you build a commercial
> package that builds only under a specific compiler and with specific
> flags set on a specific distribution with specific libraries?  You call
> that robust, best practice coding?  I call it s**t. Bloody amateur s**t.
> Written (probably) by physics graduate students who got a C- in
> programming 101 (the only course they ever took on how to program) and
> who wouldn't know an algorithm (other than one from Numerical Recipes)
> if they tripped over it.  And believe me, it's out there.  I personally
> know of a huge web-based application developed at one of our neighboring
> institutions here in the triangle that was written by a physicist as
> perl-cgi scripts on a Mac -- I kid you not -- to manage a massive
> database of information that the tool interactively presented that he
> kept as one, big flatfile.  I don't remember, 60K lines of code, not one
> comment.

Commercial, get it to compile, make it a static, make sure it runs on
all the supported "kernels" (of which some are vulnerable and have been
updated by said Distro vendor but, they require the borked version of
the kernel)

> The Southern courtroom defense for murder.  "He needed killin'". Sounds
> pretty good, doesn't it?  Maybe you can think of one or two targets...?
> SO, my friend, who KNOWS what wonders rpms could work if People Just
> Followed The Rules, were Competent Programmers, and Maintained Their
> Code.  I honestly think that if they did these things, Life Would Be
> Good and rpms would be perfectly adequate (as indeed they are, for
> nearly anything).  Or a whole lot better.

POLICY, Policy, Policy, policy... (getting tired typing p-p-p-p-policy)

> So I, like many others, groan when rpm's and yum and repos don't quite
> work the way I'd like them to, when I encounter (rarely) an application
> that isn't rpm packaged and I want to install it around, but I also
> think that the problem is MORE THAN HALF with the software developers,
> with only some fairly narrowly proscribed areas where rpm itself may or
> may not prove to be inadequate.  Mark's example of ATLAS being a very
> useful, near archetypical, case in point.  It replaces PART of some
> libraries, there are tools that can use if you've got it, there are
> libraries that will use it if you've got it and install it the right
> way, but rpm can easily get confused about just what it provides and
> whether or not it is safe to install without breaking a dependency of
> something that uses the basic e.g. lapack/blas packages.  Even this,
> though, probably depends more on the effort one spends building the rpm
> itself and less on rpm per se.

... SSSP (Same Shiite, see previous)

> The problem of building and maintaining diskless systems is another case
> in point -- rpm's db management isn't QUITE flexible enough to do all
> that needs to be done there, and although there are hacks one can use
> (usually) to make things work, they aren't as natural as one might like.
> How much of this is rpm's fault, and how much the fault of the
> underlying db software I cannot say -- it seems like there are several
> way one might try to fix it.  The rpm-devel list is there waiting for
> anybody with time hanging heavy who wants to give it a shot -- rpm 5.x
> is probably taking orders for features and suggestions right now...
> preferrably, I'm sure, from people who can singlehandedly take the
> existing sources and Make Them Happen and then help to Keep Them
> Running.  As usual.

Why worry about the whole packaging issue. It matters not. If policy is
not part of the solution, it *IS* the problem, until it is defined many
companies and individuals and organizations can't be arsed to combat
this problem. Many never will even want to address it.

>   rgb

Of whom, I (stupidly) bumped/rubbed the wrong way 10+ years ago and
formerly was on his twit list (may still be AFAIK). No need to forward
this onto him and get his dander up. (/me knows someone will though)
greg, greg@gregfolkert.net

The technology that is 
Stronger, Better, Faster: Linux

Use Debian GNU/Linux, its a bazaar thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20051011/36bbde38/attachment.pgp 

More information about the linux-elitists mailing list