Slashdot Mirror

... And tools like RPM, dpkg, as well as scripting systems like cfengine provide ways of readily deploying upgrades and of otherwise maintaining "system cleanliness." After all, you don't want to have the box go down when a log file fills up, and then need to ship out new hard drives to fix things if they do...

Well, actually, an RPM is just a tarball with dependency information. How primitive.

Debian packages, on the other hand, are tarballs with dependencies and configure/uninstall scripts. Now there's a tarball you can take home to mom


RPMs can have configure/install/uninstall scripts, and more besides. And it has done since version 2 (probably before then, I can't remember right now).

I like Debian too, but please know what you are posting is actually correct before proclaiming Debian as having the best packaging system (which it may have, but not for this reason).

Many of the features of older versions of RPM can be found in the freely downloadable book `Maximum RPM' at rpm.org, where there is some documentation. But not for rpm 4.0, as the poster mentioned.

pastie

I haven't been keeping up to date with RPM v4 as much as I'd like to, but last I knew it was beta and having problems with corrupting the RPM database. Has this changed?

http://www.rpm.org still says that the current stable version is RPM v3.0.4. Hmmm... I could have sworn that v3.0.6 was the latest in the 3.x series.

Dude, I configured my first unix back before there was a Solaris, or a SUNOS. But, I have configured a few Solaris boxes. Can't teach an old doggo new tricks? Try this: next time you need to configure a Solaris box, make life easy on yourself and go to rpm.org first. pull it down and install the gnu tools via RPM. It's a breeze.

I agree, this book sounds good to me. I'd like to see the underlying similarities in the *nixes.

I thought you just said they're not similar? make up your mind :)

RPM is also the system specified in the current LSB draft

The problem with compatibility is not package formats, but libraries, file locations etc - binary compatibility is much better than what it used to be, thanks to glibc, but is still in need of improvement.

you can do something like this with redhat kickstart installs. Once you get them working (fairly trivial, though mkkickstart doesn't really work out of the box) you can install software with about two minutes of human interaction, and then a varying amount for the rest, depending on how many packages are getting installed. You can also add any custom RPMs to the list, so as long as you know how to roll an RPM you're golden.

If you don't know how to roll an RPM then just check out www.rpm.org which includes a lot of helpful reference material, including the slightly outdated but exceedingly thorough Maximum RPM available in Postscript or LaTeX.

you can do something like this with redhat kickstart installs. Once you get them working (fairly trivial, though mkkickstart doesn't really work out of the box) you can install software with about two minutes of human interaction, and then a varying amount for the rest, depending on how many packages are getting installed. You can also add any custom RPMs to the list, so as long as you know how to roll an RPM you're golden.

If you don't know how to roll an RPM then just check out www.rpm.org which includes a lot of helpful reference material, including the slightly outdated but exceedingly thorough Maximum RPM available in Postscript or LaTeX.

you can do something like this with redhat kickstart installs. Once you get them working (fairly trivial, though mkkickstart doesn't really work out of the box) you can install software with about two minutes of human interaction, and then a varying amount for the rest, depending on how many packages are getting installed. You can also add any custom RPMs to the list, so as long as you know how to roll an RPM you're golden.

If you don't know how to roll an RPM then just check out www.rpm.org which includes a lot of helpful reference material, including the slightly outdated but exceedingly thorough Maximum RPM available in Postscript or LaTeX.

1. Install RPM 4.0.
   1. Download the RPM 4.0 tarball ( ftp://ftp.rpm.org/pub/rpm/test/rpm-4. 0.tar.gz ).
   2. Download db3, the database format used by RPM 4.0 ( ftp://ftp.rpm.org/pub/rpm/ test/db3-3.1.14-0.2.6x.src.rpm ).
   3. Build ( rpm --rebuild db3-3.1.14-0.2.6x.src.rpm ) and install ( ls /usr/src/redhat/RPMS/i386/db3-* | xargs rpm -ihv ) db3. Build ( rpm -tb rpm-4.0.tar.gz ) and install ( ls /usr/src/redhat/RPMS/i386/RedHat/RPMS/i386/rpm-* | xargs rpm -ihv ) RPM 4.0.
   4. Convert the RPM database to the format used by RPM 4.0 ( rpm --rebuilddb ).
   5. Moving the old database files ( /var/lib/rpm/*.rpm ) out of /var/lib/rpm is necessary to prevent RPM 4.0 from segfaulting.
2. Update initscripts, modutils and chkconfig to be compatible with those expected by the rawhide distribution of XFree86 4.0.1.
   1. Download the updated packages.
   2. initscripts 5.27 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/initsc ripts-5.27-1.src.rpm )
   3. modutils 2.3.11 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/modutil s-2.3.11-7.src.rpm )
   4. chkconfig 1.2.1 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/chkconf ig-1.2.1-1.src.rpm )
   5. Build and install the updated packages.
   6. rpm --rebuild initscripts-5.27-1.src.rpm ; rpm -ihv /usr/src/redhat/RPMS/i386/initscripts-5.27-1.i386. rpm
   7. rpm --rebuild modutils-2.3.11-7.src.rpm ; rpm -ihv /usr/src/redhat/RPMS/i386/modutils-2.3.11-7.i386.r pm
   8. rpm --rebuild chkconfig-1.2.1-1.src.rpm ; rpm -ihv /usr/src/redhat/RPMS/i386/chkconfig-1.2.1-1.i386.r pm
3. Build and install XFree86 4.0.1.
   1. Download XFree86 4.0.1 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/XFree8 6-4.0.1-0.30.src.rpm ).
   2. Build XFree86 4.0.1 ( CFLAGS='-I/usr/src/redhat/BUILD/XFree86-4.0.1/xc/e xport/include' LDFLAGS='-I/usr/src/redhat/BUILD/XFree86-4.0.1/exp ort/lib' rpm --rebuild XFree86-4.0.1-0.30.src.rpm ) and install the desired XFree86 4.0.1 RPMs located in /usr/src/redhat/RPMS/i386/XFree86-*. Set CFLAGS and LDFLAGS is needed else the build will complain about being inable to find some parts of xlib, which should only an issue when building on a system without XFree86 installed.

1. Install RPM 4.0.
   1. Download the RPM 4.0 tarball ( ftp://ftp.rpm.org/pub/rpm/test/rpm-4. 0.tar.gz ).
   2. Download db3, the database format used by RPM 4.0 ( ftp://ftp.rpm.org/pub/rpm/ test/db3-3.1.14-0.2.6x.src.rpm ).
   3. Build ( rpm --rebuild db3-3.1.14-0.2.6x.src.rpm ) and install ( ls /usr/src/redhat/RPMS/i386/db3-* | xargs rpm -ihv ) db3. Build ( rpm -tb rpm-4.0.tar.gz ) and install ( ls /usr/src/redhat/RPMS/i386/RedHat/RPMS/i386/rpm-* | xargs rpm -ihv ) RPM 4.0.
   4. Convert the RPM database to the format used by RPM 4.0 ( rpm --rebuilddb ).
   5. Moving the old database files ( /var/lib/rpm/*.rpm ) out of /var/lib/rpm is necessary to prevent RPM 4.0 from segfaulting.
2. Update initscripts, modutils and chkconfig to be compatible with those expected by the rawhide distribution of XFree86 4.0.1.
   1. Download the updated packages.
   2. initscripts 5.27 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/initsc ripts-5.27-1.src.rpm )
   3. modutils 2.3.11 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/modutil s-2.3.11-7.src.rpm )
   4. chkconfig 1.2.1 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/chkconf ig-1.2.1-1.src.rpm )
   5. Build and install the updated packages.
   6. rpm --rebuild initscripts-5.27-1.src.rpm ; rpm -ihv /usr/src/redhat/RPMS/i386/initscripts-5.27-1.i386. rpm
   7. rpm --rebuild modutils-2.3.11-7.src.rpm ; rpm -ihv /usr/src/redhat/RPMS/i386/modutils-2.3.11-7.i386.r pm
   8. rpm --rebuild chkconfig-1.2.1-1.src.rpm ; rpm -ihv /usr/src/redhat/RPMS/i386/chkconfig-1.2.1-1.i386.r pm
3. Build and install XFree86 4.0.1.
   1. Download XFree86 4.0.1 ( ftp://download.sourceforge.net/pub/mirrors/redhat/ rawhide/SRPMS/SRPMS/XFree8 6-4.0.1-0.30.src.rpm ).
   2. Build XFree86 4.0.1 ( CFLAGS='-I/usr/src/redhat/BUILD/XFree86-4.0.1/xc/e xport/include' LDFLAGS='-I/usr/src/redhat/BUILD/XFree86-4.0.1/exp ort/lib' rpm --rebuild XFree86-4.0.1-0.30.src.rpm ) and install the desired XFree86 4.0.1 RPMs located in /usr/src/redhat/RPMS/i386/XFree86-*. Set CFLAGS and LDFLAGS is needed else the build will complain about being inable to find some parts of xlib, which should only an issue when building on a system without XFree86 installed.

RPM is the most-used, and often, most-hated of the options, with Debian's dpkg/dselect and BSD Ports vying for the "most-loved" status.

The Ports use of what amount to "just plain makefiles" gives it the merit of being the most "traditionally-UNIX-like" packaging scheme.

Is there likely to be any "convergence" of the sort where libraries are added/modified so as to maximize the ability to use something like Ports?

I left Slackware in about '95 in favor of what I saw then as improved manageability of Red Hat's RPMs. I have since migrated to Debian, which provides better answers than RPM. It would be interesting to see the tide turn back due to Ports providing more deeply improved system manageability...

that's a great idea. Already, when I am called upon to admin a Solaris box out of the... er... box, I always set it up using RPMs (Redhat's package management system).

http://www.rpm.org/ has everything you'll need. You'll probably have to learn how to rebuild source RPMs which you've thus far avoided, but it's worth it, because suddenly a vast wealth of software becomes available and very easy to install, and very easy to deploy to a number of servers.

• The "ever paranoid" Debian folks, who have been rather paranoid about RPM because RHAT wouldn't assure them that it would never be released in proprietary form have commented on Corel's participation, at Strategic Alliance Between Corel, KDE and Debian , with the comment:

  "I am very happy to see Corel taking this step into the Open Source world and cooperating with non-commercial organizations such as Debian and KDE," said Wichert Akkerman, Debian's project leader. "By combining Debian's strengths, which include having a large number of developers, a very open development model and a public bug tracking system, with the experience Corel has with making office and desktop products, I think we will be able to produce an outstanding system with the best of both worlds."

• If you were not previously aware, Corel HAS been involved with development efforts on Linux for quite some time.

  See: Corel's Contributions to the Wine Project

That has some (arguable) merits in and of itself; see Clueless users are bad for Debian.

On the other hand, the fact that Debian provides a public Bug Tracking System, and provides some published Distribution Construction Policy that includes Packaging methods/policies means that there is considerably more useful structure than RPM provides.

In particular, since these policies have been designed with a view to being amenable to automation, this means that Debian makes a very good base on which to construct customized distributions where much of the maintenance can be automated. This is why there are so many ports, both to diverse architectures (ARM, MIPS, SPARC) as well as to build on some particular infrastructures ( Beowulf ) and even other operating systems ( Hurd ).

The other effect of all this is that creating a variation on Debian doesn't mandate creating a whole huge amount of testing infrastructure, as is necessary to "fork" variations on distributions like Red Hat, where there is not a clear path to get patches back upstream; a Debian "fork" can more reasonably use the existing infrastructure.

It looks like the Corel, Storm, and other such variations on Debian largely involve taking Debian,

• Replacing the initial installation tools with cool new ones, which doesn't disturb the rest of the distribution, and
• Adding some special packages, which again doesn't forcibly disturb the rest of the distribution.

Due to its ability to multiplex together package sources using apt-get, Debian looks to be a better candidate for this sort of "customization" than just about any other.

• Java

  There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.

  Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.

  Is anybody near to deploying a complete "libre" Java for Linux?

• System Config Tools

  There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.

  Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.

  Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?

• Testing/Standards

  There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.

  There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.

  ... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.

  And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.

  But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.

  We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.

  Question: What are you doing to help contribute to the public body of test suite code?

RPM has been updated to verion 3.0, available here.
Christopher A. Bohn

As for RPM being proprietary, have you ever visited www.rpm.org, where the specifications, thorough documentation, the source, and more, for RPM is available, including a port to Solaris (which works great, btw.).

If that's proprietary, I wonder what isn't. Oh, and if you insist on tar, gz, etc, there's a small script called rpm2cpio that strip of the RPM header so you can use cpio to extract the archive.

As for being standard, cpio is way more standard than tar.gz - there's still commercial Unices that are shipped without gnu tar or gzip.

We have lots of them already. We don't really need to have yet another place where developers (or other interested people) have to maintain release information.

I don't disagree that there is a need for more "metadata" about software, and that it is valuable to have reviews that can assist people in selecting from (say) the large number of word processors, spreadsheets, or databases.

The LinuxBerg effort is nonetheless duplicative of information being maintained elsewhere.

Anyone who has worked on database systems should remember the notion of normalization. If a database is suitably normalized, data will be distributed out to various tables, and will be addressable using a multiplicity of views.

Thus, Freshmeat has a nice listing of software releases, and some critical URLs thereof. That information is nicely exported on an hourly basis in a single database file. SAL doesn't seem to have a single export of the data that they have collected, but certainly have similar data in some form of database. rpm2html provides utilities to take sets of RPM files and generate XML RDF that provides a crosslinked database of packages, dependencies, and their sources.

The world doesn't very badly need Yet Another Manual Archive of what amounts to the same data. We need something like an XML DTD for the interchange of this data so that the various sites can import/export data from other sites, thus diminishing the need for human effort in creating each of these databases.