Jeremy Davis's picture

I've been playing with a few (well actually lots) of ideas for TKLPatches to contribute and I have a dev question.

Obviously if packages are available in the repos is the ideal situation. However if they are not, what is the hierarchy of preference beyond that? For example there seems to be a number of different approaches depending on the project: preconpiled .debs (or .rpms - which could be changed to .debs with alien), binary tarballs (usually with install script), source tarball or other source such as svn or git.

I guess the potential problem with svn or git is that while it may work when the patch is made, it potentially creates unpredictability. If a buggy version is uploaded after I create the patch then another user tries the patch it won't work as expected. How would you work around this? How would you go about making some sort of package from svn/git? And what would be the best (and/or easiest) format to create? .deb? .tar.gz?

Alon Swartz's picture

Good question, these are the guidelines we "usually" follow (there are exceptions, and they are not set in stone, especially when dependencies are involved):

We usually prioritize using a deb package, then release tarball, then checked out revision control.

  • Use package from distro/release (e.g. Ubuntu/Lucid)
  • Use package from distro/release-backports (e.g. Ubuntu/Lucid - are backports available yet from Maverick?)

From this point, the package would be included in the tklpatch (and documented).

  • Backport package from distro/release+1 (not relevant yet as Maverick isn't out yet)
  • Import package from upstream or debian/testing or PPA (if packager can be trusted)

And finally, the source

  • Tarball source available from upstream (stable release)
  • Checked out revision control (as a last resort)

Including self compiled binaries in tklpatches isn't usually a good idea...

Rudiger Wolf's picture


First, what is Quickly?
Taken from Launchpad:

Quickly helps you create software programs (and other things) quickly. You can select from a set of application templates and use some simple Quickly commands to create, edit code and GUI, and publish your software for others to use. Quickly's templates are easy to write. So if you are a fan of language foo, you can create a foo-project template. Or if you want to help people making plugins for your killer app, you can make a killer-app-plugin template. You can even create a template for managing corporate documents, creating your awesome LaTeX helpers The sky is the limit!
Given the richness and variety of the Linux platform, programming on Linux should be easy and fun. However, it's not easy and fun because it is too hard to learn. It is too hard to learn because there are too many choices, and too much information to wade through. Quickly strives to make programming easy and fun by bringing opinionated choices about how to write different kinds of programs to developers. Included is a Ubuntu application template for making applications that integrate smoothly into the Ubuntu software infrastructure.
GTD is easier with GTQD (Get Things Quickly Done)!
In a nutshell, creating application should be FUN and EASY.

What about the packaging? See part 9 of the tutorial.

We are now almost ready to land! Here is the last part of this long suit of blog posts about Quickly.
Packaging your project
It's the last, but not the least issue when you are writing your software: once your application is functional, you surely want to enable other users to install it. Well, you can give it into a tar.gz and run from a trunk, but what about creating a nice package, containing all dependency information for you[1]? Let's see how to achieve this automagically.

Liraz Siri's picture

I'm downloading the source code now and will take a closer look at this later.

In general I'm a bit skeptical of overly generic template frameworks because often they just get in the way. They become another layer of complexity you have to understand before you can get stuff done. Especially if you can program your own custom solutions when an opportunity for automation presents itself.

On the other hand circumstances matter. Sometimes you really can make a decent trade off between the total flexibility of a programming language and the ease of use of a generative tool, though I still suspect that any sufficiently powerful tool eventually just becomes (or embeds) a fully fledged programming language.

Jeremy Davis's picture

Sorry I haven't acknowledged this sooner. Lots of valuable info for me here :)

Add new comment