"It wasn't raining when "First they ignore you,
Noah built the ark." then they laugh at you,
-- Howard Ruff then they fight you,
then you win."
-- Mahatma Ghandi
When I kicked off our OpenPKG Project in November 2000, except knowing
very well where I wanted to go, I had nothing more than a bunch of
initial software installation scripts (in BnP/Perl format) flying around
in my home directory (see http://www.openpkg.org/project/history.php for
more details about the OpenPKG history).
The bootstrap package [0] (at this time still named just "rpm" ;-)
was -- and actually still is -- the most challenging and most cool
package. Although it is far away from being an elegant piece of software
engineering, even after 6 years I'm still rather proud about it as I
consider it one of my masterpieces of Unix hacking tricks. If you are a
Unix developer and want to easily become crazy within a single day, I
recommend you to dive into our "openpkg" package -- looking and trying
to understand all of its subtle details makes you either totally crazy
within hours or, if you survive, you can really feel blessed as a Unix
hacker ;-)
Then the "make", "gcc", "perl", "openssl" and "openssh" packages
were one of our first. These packages nowadays are well known in the
OpenPKG world as one of the few CORE class packages. Just for packaging
"gcc" (at this time still at vendor version 2.95) I required even a
few _weeks_ because of the necessary fiddling with GCC's nasty build
environment of these older times. Thanks to Autoconf and friends this
has changed dramatically (at least for most pieces of software) during
the last years.
And then immediately came our "all dancing, all singing" package:
"apache" [1]. Since its earliest times it was an extremum in every
aspect. It has one of the largest and most complex .spec files, it
has over 60 build-time %options, it is spiked with a large number of
resulting %if/%else/%endif constructs, it was revised a few hundred
times in total, etc.
Well, perhaps it is such complex because Apache 1.3's vendor build
environment is such strange. Hmmm... as I know the developer of this
Apache 1.3 build environment on a first name basis, perhaps I should
just direct my complains directly to him. Ops, seems like I then have to
blame myself ;-) At least, if you ever want to see how far one can go
with a single OpenPKG RPM package, look at this one.
Well, and today, after exactly 6 years of steadily development and over
81000 CVS repository transactions [2], I'm very proud to announce that
in OpenPKG-CURRENT we now have:
_ ___ ___ ___
/ | / _ \ / _ \ / _ \
| || | | | | | | | | |
| || |_| | |_| | |_| |
|_|o\___/ \___/ \___/
high-quality, concise and clean
OpenPKG RPM packages [3]
And since recently, all those 1000 packages are now
easily browsable, searchable and reviewable online under
http://www.openpkg.org/product/packages/
- - - -
"To create quality software, "It worries me however, to realize
the ability to say no is usually how tough an ass-hole I have had to
far more important than the be, in order to get to stick to the
ability to say yes." principle of doing things right,
-- Michi Henning rather than 'just hack it in'."
-- Poul-Henning Kamp
But, why is this raw number of packages of any interest? The FreeBSD
ports collection even counts 15.000 packages and Debian counts over
20.000 packages AFAIK!?
Well, if those 1000 OpenPKG RPM packages would be just the result of
simple copying & pasting a few lines of packaging specification of other
vendors, this would be no remarkable achievement (and could have been
achieved within a much shorter time, of course).
But we did all this really 100% from scratch, with a very small team
of core developers and the resulting packages are really ultra concise
and clean ones (in contrast to just providing the plain software
packaging functionality). And it was never our goal to package "just
everything flying around" (what FreeBSD ports and Debian more or less
do). Additionally, although we also have some small number of desktop
applications packaged, we always focused (and still focus) on server
applications only.
Thanks to our extremely restrictive quality assurance via automated
"linting" (those who do not know: on every package commit transaction
the sources are first automatically checked for syntax and semantic
errors), even after 6 years of bi-daily updates and improvements,
we have no single package which has any major or minor syntax or
style discrepancies. All of our 1000 packages are fully aligned and
consistent.
Yes, I know, some developers now cry as they often wished OpenPKG's
development guidelines would be a lot less strict. But, sorry, that's
what OpenPKG RPM source packages are all about by design: conciseness
and cleanness. And this we were able to achieve over the time range of 6
years via extremely strict development guidelines only ;-)
OTOH, yes, I know very well that most of our users are neither aware of
nor interested in those facts. They more or less just want perfectly
working software packages. Well, I'm confident OpenPKG provides this,
too. At least after 5 years of being deployed in large production
setups, we know that our current OpenPKG status provides both a very
complete set of software package for Unix server computing and a
rock-solid run-time of those servers and their services.
We will try hard to keep OpenPKG for you at the quality level
it currently is, also in the future...
Yours,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
[0] http://www.openpkg.org/product/packages/?package=openpkg
[1] http://www.openpkg.org/product/packages/?package=apache
[2] | $ egrep "^[AMDT]" history | wc -l
| 81065
[3] | $ ls -l */*.spec | wc -l
| 1000
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List openpkg-users@openpkg.org
