?

Log in

No account? Create an account
packaging play-by-play - max spevack's blog — LiveJournal [entries|archive|friends|userinfo]

[ website | My Website ]
[ userinfo | livejournal profile ]
[ archive | journal archive ]

packaging play-by-play [Jun. 15th, 2011|02:36 pm]
Max
[Tags|]
[Location |garner, nc]

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.
LinkReply

Comments:
[User Picture]From: pfrields.id.fedoraproject.org
2011-06-15 07:08 pm (UTC)

Great idea.

Yes. Mel Chua has also explained this idea at a recent FUDCon talk (the one about making croissants (http://blog.melchua.com/2011/02/01/ive-followed-your-instructions-and-i-still-cant-bake-croissants/)) so I know this idea is starting to get some traction.

It's not enough to dump people at a wiki page of small text that is 10 screens long, and say, "Just follow the page." Some of the most successful adult learning I've seen follows the "tell me, show me, have me do" model, and you can't really skip that second step or everything falls apart in the learning environment.

There is possibly a built-in level of resistance, for a task like packaging, to making it "too easy," such that someone can get a package into Fedora and then fail to properly maintain its content because packaging is currently at the edge of their capability. But without building someone's confidence acting in a technical capacity, they're unlikely to ask the questions that will help them extend that edge.

Maybe one thing we need is a more definite answer to the skills you must possess to be a packager. It's got to be more than "ability to read" and "ability to type things at a prompt," of course. But it doesn't have to be as much as "deep understanding of GNU autotools" to still effectively maintain something in Fedora. We can support a range of skill levels while helping people bridge gaps that let them extend their ability to deal with technical problems. It shouldn't be a matter of each person having to individually expend the cycles to figure out the things we could easily teach -- because that stops us from scaling.

I think packagers probably only need to understand:
  • Familiarity with the CLI environment

  • Ability to effectively use an editor

  • General understanding of the concept of compilation

  • General understanding of the concept of libraries


Granted, many of our packagers know much more than this, and the more you know, the more effective you can be. The essentials for any of the additional topics could be taught fairly easily, at least to the extent that a packager needs to understand them.
(Reply) (Thread)