Ed's Blog

The other day I built my first package using Conary, and it was an eye-opening experience.

Sitting in the rpath offices, I get to hear many interesting things from the engineers. But there was one comment in particular that I thought was especially interesting (I'm paraphrasing here):

"When we find something that the packager would normally have to handle on their own, we try to come up with ways of having Conary do it for them. That way, we can solve the problem once, and it makes packaging that much easier."

I got to experience the implications of this philosophy firsthand.

The software I chose for my first packaging attempt using Conary was Zile -- a *very* small (~100K) editor that supports a surprisingly large subset of the basic Emacs key sequences.

Side note to those of you that have just now gone, "Ah ha! An Emacs user!":

Yes, I am a long-term (~25 years) member of the Cult of the Iron Pinky. I hold no ill-will toward the :wq Clan, and will countenance no ill-will in return. Keep a sense of humor, and one of these days Uncle Ed will tell you the story of how vi trounced Emacs (yes, we lost) in a paintball match at the '98 Linux Expo, ok?

Back to our regularly-scheduled post.

I felt that Zile would be a handy little editor to have around for those of us that use Emacs more than vi, and wanted a small-footprint editor (either for quick editing tasks, or to put on something like a dedicated firewall/appliance box).

To get started, I downloaded the Zile tarball from SourceForge, and took a look. The INSTALL file noted that it was built using the "./configure/make/make install" drill that is pretty darn common these days.

I also noted that, by default, it wanted to install everything in /usr/local/ -- I'd have to deal with that (there's just no sense in packaging software so that it installs in /usr/local/), but I thought I'd just hack together a quick recipe file (Conary's equivalent to RPM's spec file) first, and try a quick local cook (build, for you RPM types in the audience).

Here's the first iteration of my Zile recipe file, in its entirety:

class zile(PackageRecipe):
name = "zile" version = "2.2.2" def setup(r): r.addArchive('http://unc.dl.sourceforge.net/sourceforge/zile/zile-%(version)s.tar.gz')
r.Configure() r.Make() r.MakeInstall()

Seemed pretty simple. I figured that I'd need to do some additional tweaking to get something ready for prime-time, but hey -- why not give it a try?

I typed cvc cook zile.recipe and hit return.

I watched as the tarball specified by r.addArchive was downloaded (after downloading, it was automatically cached on my machine so subsequent cooks using the same tarball wouldn't need to download it each time.) Then the build started...and completed...and a changeset file was written.

My first Conary package was built!

But what did the package look like? Was it even usable? After all, I really didn't do anything other than to tell Conary what I was packaging, where to find it, and the basic steps required to build and install it. There had to be more to it than this...

To figure out what else I needed to do, I installed the changeset file using conary update.

Hmmmm, no errors there.

Then, I typed zile and up came Zile's startup screen. It worked!

Looking a bit more closely, I saw that all the right things were done with the software, right down to changing the default install path from /usr/local/ to /usr/. This software was packaged and ready to go.

I was amazed -- this was nothing like my past experiences packaging software with RPM.

Emboldened by my speedy success, I asked my coworkers if I could have commit access to our repository on contrib.rpath.com. Nobody laughed hysterically at the thought, so officemate Michael created a username/password on the contrib repository for me.

Three commands later (cvc add zile.recipe ; cvc commit ; cvc cook zile), and my baby was cooked, with the source and binaries committed into the contrib repository, and ready for anyone to install.

(You can check out my handiwork here.)

To make sure people knew what Zile was, I used a neat feature of Conary repositories -- a single mouse click, and the Zile's description text from freshmeat.net was added to the contrib repository.

While all this was easy, Zile is a pretty small and simple app. Is all software as easily packaged as Zile? Honestly, no -- you're not going to cook something like glibc or a kernel using a recipe this simple. But think about how much software out there builds with just ./configure ; make ; make install. For software that builds as easily as Zile, packaging using Conary can be just this easy.

I looked over my recipe again, now that it was publicly available. I made some minor tweaks to it, and recooked/committed.

There -- until the time upstream releases a new version, I was done with Zile.

Later, I noticed that Michael made some changes to my recipe. He must've seen the commit emails that are generated when I committed Zile to the contrib repository. I looked over the recipe, and my jaw dropped.

He actually made it simpler:

class zile(AutoPackageRecipe):
name = "zile" version = "2.2.2" buildRequires = [ 'libtermcap:devel' ]
def unpack(r): r.addArchive('http://unc.dl.sourceforge.net/sourceforge/%(name)s/%(name)s-%(version)s.tar.gz')

(Michael explained that I really should've included a buildRequires line right from the start as he showed me how to use the output of conary showcs to display the libraries required by my Zile changeset file.)

Looking at Michael's recipe, it struck me that here was that philosophy in action -- the ./configure ; make ; make install sequence is pretty common, so why force packagers to explicitly specify it time after time after time? Instead, modify Conary to make this common situation that much easier to package.

And everyone is happier.

Post details: Now that's easy!

08/09/05

05:12:54 pm Now that's easy!

Comments:

Comment from: Nick Pollitt [Visitor]