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?

Forum: 
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...

Jeremy Davis's picture

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

Add new comment