Packaging: Need Help!

I haven’t had much time to blog about interesting things, sorry guys. But I did want to take an opportunity to share a problem I’m having.

I make software, and I make it for people. I’ve driven by people’s needs. So I tend to make lots of smaller things to fix certain problems or do something interesting on a small scale. The difficulty I’m having is with packaging and getting packages into Debian and thus into Ubuntu. I make lots of PPAs and they seem to work for users who are interested in getting what I do directly from me. But…

I feel that as the developer, designer, QA and possibly only user; that to do all the work on the packaging and being the sponsor in the upload process would deny my projects much needed oversight, not to mention being tiresome.

If you check out my launchpad list of code branches, I have A LOT of really awesome code which isn’t in the Ubuntu archive. I have a lot of interesting and useful tools which should be available to all kinds of people and just aren’t. The reason why all these code branches have failed to move anywhere is because I’m not good at asking for help on packaging and when I do I ask the wrong people. Despite on a number of projects being asked by users to get packages into Ubuntu, the answer is simply: I can’t do it myself and I need help.

If you know how to get code into Ubuntu _without_ having to be the packager and Debian maintainer: let me know you thoughts, as always below.

6 thoughts on “Packaging: Need Help!

  1. Martin,

    i know you didn’t ask for rpm packaging specialists for help, but I think you’ll gain something from my perspective as a distribution packager on how to provide breadcrumbs for packagers more generally. We really do need some breadcrumbs. Simple things, like a useful readme, or install instructions, or just a descriptive summary of purpose go a long way. Packagers are the people who you are relying to build your project from source, so you need to gear some information towards them so they can do the work.

    How do I find out which of those code branches are actually useful code? Some of them list has empty branches on that summary page. And the most recent commit log isn’t useful information at all from an independent packager pov.

    How do I get a quick summary of what each of those projects actually do? My random clicks brought me to lp pages with a distinct lack of contextual information that describe the functionality for the branches i selected. Asking packagers to click their way through a list of branches isn’t motivating at all. It would help if there were descriptive summaries of each project on a project page for each project you want to see packagers help you with.

    Some of them don’t even have readme files in the code trees. And some that do, the readmes are no help to me as a packager to give me clear information on purpose nor for installation from source. The sessesion management readme for example. It’s just a brain dump for your development purposes. not info on how to take the code and use it from source.

    Have you done any versioned released for any of these codebases or are they all just rolling bzr checkouts? Speaking a distribution packager from another distribution, I really…really… like versioned releases with hash signatures…as an initial packaging target. From a packager pov, development tree checkouts are something you start using once you have a good working relationship with upstream, they a seldom a good starting point for packaging.

    Lp is great for scratching your own itch when it comes to writing code. But its _horrid_ at communicating information about project utility when you need to start interacting with people who are not intimate with the code. The Lp project summary pages are distinctly bad in this regard compared to other hosting options.

    Looking at the lack of information you have currently provided about the functionality of the codes or how to actually install them from source, I wouldn’t personally volunteer my time to work on packaging any of them for my distribution of choice, when there are other projects that are easier to get started with with installation and testing. Not that they aren’t interesting, but it looks like an uphill climb to even figure out what these projects are and how to work with the source.

    The fact that you already provide deb scripting for your own PPAs might lower the bar for some debian packagers, but if a debian packager wants to redo the packaging specific bits for themselves as part of their due diligence and ownership of the packaging, they very well might want the same information that I’m looking for. with regard to working with the sources.


  2. Jef – Excellent comment, thanks. A lot of the code bases do have project pages and some even have releases. But they’re not easy to find. I guess I should make sure all the projects have all the administrative red tape tied down before I expect anyone to package them down stream.

  3. Martin,
    You might find this useful as a checklist. It’s a little tongue-in-cheek, but the points of fail are a good rule of thumb on how to make sure you are organizing things well as an “upstream”. Just skip the first few slides about cloud computing.

    Or just try to imagine someone from a different distro using a different packaging system that you personally aren’t familiar with was trying to package this up. Someone familiar with Gentoo’s ebuild or rpath’s conary schemes but not with .deb. What would they need to know to work with the codebase and do some pre-packaging testing? There’s a good chance you been encoding some of the useful info into the .deb scripts as part of your personal workflow.


  4. Jef- Thanks for the link, the information in that presentation is good, but it need unpacking into a readable format, I have an urge to copy and paste everything into a text file. Side note: Tom Callaway >:-(

Comments are closed.