You are here
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?
Good question
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.
From this point, the package would be included in the tklpatch (and documented).
And finally, the source
Including self compiled binaries in tklpatches isn't usually a good idea...
Thanks guys
Sorry I haven't acknowledged this sooner. Lots of valuable info for me here :)
Add new comment