max spevack's blog - packaging play-by-play [entries|archive|friends|userinfo]

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

packaging play-by-play [Jun. 15th, 2011|02:36 pm]
Previous Entry Share Next Entry
[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: alg0rhythm
2011-06-15 07:07 pm (UTC)

YES!

(Link)

I would be up for a clear tutorial on how to package. I have been interested in becoming a packager but the threshold seems to high. While I have created a spec file and rpm on my own computer, I don't think I have the chops to create a package for fedora that would pass muster. The wiki has a lot of info on packaging but it is not very straight forward. Let me know when some tutorial materials are available, I'll test drive them.
-- Jeff
[User Picture]From: pfrields.id.fedoraproject.org
2011-06-15 07:08 pm (UTC)

Great idea.

(Link)

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.
From: (Anonymous)
2011-06-15 09:48 pm (UTC)

(Link)

I once attended a classroom on i believe it was packaging fonts. It was very informative. I asked a question "what makes a packager a good packager" and unfortunately my question was misinterpreted as "what makes you a good packager", and i did not notice this until when the session was over (English is not my native language). I already had an idea of what the answer to "my" question would be: namely: experience.

Unfortunately "fedora-infrastructure" seems to have felt the need to cut back on valuable resources like these because all Google was able to turn up was "Error 503 Service Unavailable".

But anyhow what i often see, as a SELinux guy, with packagers are issues like where do i stick stuff, and considering the hard stuff like dealing with dependencies it seems that there is plenty room for improvement when it comes to packaging.

I think packaging can be complicated matter depending on what you are packaging. The question i would like to pose is how can we teach the packaging matter that cannot be taught in 50 minutes (the experience).

I am a practical guy i learn by doing and i like your idea of having a teacher or some one you can look over his shoulder and learn.
From: (Anonymous)
2011-06-15 10:07 pm (UTC)

Didn't we at least start on this already

(Link)

It seems like at the Marketing FAD that Paul and I hacked together a simple php library spec that was just littered with comments explaining where you'd get appropriate vlaues to put in fields, what each section did, etc.

I'll try and dig that up, but Paul may have it.

It's not a complete solution, but it's a start.


--David
[User Picture]From: spevack
2011-06-16 03:40 am (UTC)

Re: Didn't we at least start on this already

(Link)

That would be awesome. I'm sure stuff exists, that I simply haven't seen.
From: (Anonymous)
2011-06-15 10:25 pm (UTC)

That's what i do !

(Link)

Hey Max, thats exactly what RPMDev is all about, teaching and recruiting new packagers (and developers).

Im think to go further with and thinking hard about a potential rpmdev.fedoracommunity.org (U for fedora packaging and developing apps with Fedora)
From: Severin Gehwolf
2011-06-16 03:59 pm (UTC)

Have a look at Fedora Packager for Eclipse

(Link)

Hi Max,

Our tool, Fedora Packager for Eclipse[1], should make Fedora packaging easier. We provide a simple GUI for basic packaging tasks, such as building packages locally, push koji builds, dist-git integration and much more.

It works quite well for existing packages in Fedora Git, but work is under way to improve the experience for new packagers as well. In particular we'd like to make it easier to create a new Fedora RPM project, build it locally, test it with mock builds, submit it for review via one click of a button and being able to push it to Fedora Git once the review has gone through.

For starters, have a look at our extended user guide[2]. Feedback, feature requests, bug reports and contributions are always very welcome[3]. Keep up the good work! Let me know if we can help putting together such a class.

Thanks,
Severin

[1]https://fedorahosted.org/eclipse-fedorapackager/wiki (https://fedorahosted.org/eclipse-fedorapackager/wiki)
[2]https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide (https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide)
[3]https://fedorahosted.org/eclipse-fedorapackager/newticket (https://fedorahosted.org/eclipse-fedorapackager/newticket)