Max (spevack) wrote,

  • Location:

packaging play-by-play

Over the weekend, I watched as Paul worked his way through the packaging of Pinpoint, and it got me thinking about what I see as the gap in our ability to teach packaging to others.

We've got tons of resources that discuss how to package, and how to get your package into Fedora, but what I'd really like to see is a presentation that shows the entire play by play.

What do I mean by that?

Well, let's try to re-create the different things that Paul had to do in order to package Pinpoint, which is probably about a 4 or a 5 complexity, on a scale of 1 - 10.

* Make sure his computer has all the right tools.
* Make sure he has all the proper Fedora permissions.
* Understand not only what all the different fields in a spec file mean (which we have good documentation for), but also figure out what to actually put into those fields. How does a person know if what is being entered is right, wrong, or right-but-not-optimal?
* Building the package and testing it.
* Submitting the package for review.
* etc.

I think we need to get some presentations that can be shown in Fedora Classroom or in FUDCons that actually walk someone through the entire play by play, and explain the why and the how for each step.

We should do this for packages that are both really easy (some Drupal and Python modules, perhaps) as well as packages that are mid-level complexity. Down the road, maybe we get into an advanced class.

Here's a specific example of what I mean, taken from the wiki:

BuildRequires: A comma-separated list of packages required for building (compiling) the program. These are not automatically determined, so you need to include everything needed to build the program. There are a few packages that are so common in builds that you don't need to mention them, such as "gcc"; see the Packaging Guidelines for the complete list of the packages you may omit. You can also specify minimum versions, if necessary, like this: "ocaml >= 3.08". You can have more than one line of BuildRequires (in which case they are all required for building). If you need file /EGGS, you can get its package by running "rpm -qf /EGGS"; if EGGS is a program, you determine its package quickly by running "rpm -qf `which EGGS`". Try to specify only the minimal set of packages necessary to properly build the package, since each one will slow down a "mock"-based build (e.g., try to use sed instead of perl if you don't really need perl's abilities). Watch out: Some applications permanently disable functions if their package isn't detected during the build; in those cases you may need to include those additional packages. If you have trouble figuring out this list, the "auto-br-rpmbuild" command (from the auto-buildrequires package) may be helpful.

I can read that and have an idea of what is being said, but until someone shows me both a trivial and a non-trivial example in practice, I won't really understand how to go about figuring these things out for the package that I want to create.

There's an example of a spec file for the eject utility (which is probably a 1 or 2 complexity), but nothing that shows someone how that example was actually created, and that's a key piece of learning that is missing.

Packaging is one of those things that seems really difficult, until you have a good teacher who can show you the best ways to do it. Passing on good, well-established knowledge is critical, especially if we want to give newer contributors a way to take over the maintenance and new packaging of easier projects.
Tags: redhat

  • till we meet again, goodbye

    This blog is now retired. Please visit my new blog. Several of my career changes at Red Hat have been announced on this blog. My first post was…

  • fedora regional support budget summary

    At the end of July, we'll be 5 months (42%) of the way through the fiscal year, which begins each March 1. I thought it would be useful to compare…

  • southeast linux fest, day 2

    Saturday at SELF was a pretty standard conference day of talks and hallway chats. Paul wrote some nice words about my talk. The abstract for my…

  • Post a new comment


    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic