[med-svn] [Debian Wiki] Update of "DebianMed/HowToGet" by TimBooth

Mon Aug 8 16:20:16 UTC 2011

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "DebianMed/HowToGet" page has been changed by TimBooth:
http://wiki.debian.org/DebianMed/HowToGet?action=diff&rev1=5&rev2=6

Comment:
This is getting there... still editing

  
  == Q. What about Ubuntu? ==
  
- A. Debian Med packages automatically become part of Ubuntu, but this process takes time so the Ubuntu package will often be behind the one in Debian Sid.  As with Debian, new packages and non-critical updates are not added to an Ubuntu release after the release freeze (a month or so before the release date). And packages in the experimental section of Debian may not be acceptable for the Ubuntu main distributions. 
+ A. Debian Med packages automatically become part of Ubuntu, but this process takes time so the Ubuntu package will often be behind the one in Debian Sid.  As with Debian, new packages and non-critical updates are not added to an Ubuntu release after the release freeze (a month or so before the release date). And packages in the experimental section of Debian may not be acceptable for the Ubuntu main distributions.
  
- To help the situation, [[https://launchpad.net/~debian-med/+archive/ppa|Debian Med uses a Personal Package Archive on Launchpad]].  This allows any Debian Med developer to backport packages to any release of Ubuntu, making use of the Launchpad build system. But this is not automated and is not a priority for most packager. You may need to ask for a specific package on the mailing list.
+ The process for getting the packages into Ubuntu is the responsibility of the [[https://wiki.ubuntu.com/MOTU|Ubuntu MOTO developers]] and follows a [[https://wiki.ubuntu.com/UbuntuDevelopment/Merging|set procedure]] aided by the [[https://merges.ubuntu.com/|Merge-o-Matic system]] system.  Critical updates applied to already-stable releases are added separately in Debian and Ubuntu by the relevant local maintainers, but these are fairly rare among the packages maintained by Debian Med.
  
+ To help the situation with Ubuntu packages being out-of-date, [[https://launchpad.net/~debian-med/+archive/ppa|Debian Med uses a Personal Package Archive on Launchpad]].  This allows any Debian Med developer to backport packages to any release of Ubuntu, making use of the Launchpad build system. But this is not automated and is not a priority for most packagers. You may need to ask for a specific package on the mailing list.
+ 
- == Q. But I want a package that isn't in the Debian Archive, or a newer version of one that is. What can I do? ==
+ == Q. I want a package that isn't in the Debian Archive, or a newer version of one that is. What can I do? ==
  
  A. Supporting backports (newer packages to work on an older Debian or Ubuntu base) is something we do not currently do, but we recognise that this is a common need, especially given the rate of development of many scientific applications and the understandable tendency of departments to run a Stable OS platform (either Debian Stable or Ubuntu LTS) as opposed to Debian Testing.
  There are various ways you might try to get newer packages on your system.  These are not without their problems, and in many cases will be no easier than compiling from source, but may be useful for many people.
@@ -33, +35 @@

  
   1. Try installing packages from the newer Debian or Ubuntu release directly.  If the package installs cleanly then in theory it should work.  Packages can be downloaded from [[http://packages.debian.org|packages.debian.org]] or [[http://packages.ubuntu.com|packages.ubuntu.com]] respectively.  The downside is that some packages will not install cleanly due to missing dependency requirements, and even if the package installs you will miss out on automatic updates.
  
-  1. Try doing the backport yourself.  (Link to instructions for quick-and-dirty package building)
+  1. Try doing the backport yourself, by building a source package into a binary DEB.  See the next question.
  
- == Q. I succeeded in making a package compile, how do I contribute my build for others to use? ==
+ == Q. As a user, can I download anything directly from Debian Med? ==
  
- Add info or link here.
+ A. As stated above, Debian Med does not directly distribute any ready-to-run software, because Debian/Ubuntu/etc. are the distribution mechanisms.  We make what are referred to as source packages, but these are in fact the instructions needed to automatically build the upstream source of an application into the DEB packages which you can install on your computer.  We share these via SCM repositories like Subversion or Git (different developers prefer different SCM systems) and you can access these if you want to try building a DEB for yourself.  All packaging work (not limited to Debian Med) can be browsed through the portal at [[http://anonscm.debian.org]].
  
+ == Q. What's the easiest way to build a Debian Med package from source myself? ==
+ 
+ A. If you are familiar with building applications from source ''(configure ; make ; make check ; sudo make install)'' then building .deb packages is fairly similar.  In theory, the packages should all build by a standard process, but as code and dependencies change you may need to do some tweaking to make the build work.  There is [[HowToPackageForDebian|plenty of information on-line]] but by way of illustration here is a recipe to build [[http://www.ebi.ac.uk/~zerbino/velvet/|Velvet 1.1.05]] and make a .deb package on a fresh Ubuntu 11.04 box.
+ 
+ {{{#!highlight bash
+  #Install essential tools
+  sudo apt-get install subversion devscripts quilt
+ 
+  #Make a work area
+  mkdir -p velvet-build/latest
+  cd velvet-build/latest
+ 
+  #Fetch build metadata from SVN and pull original tarball from upstream site using uscan,
+  #then unpack it.
+  svn co svn://svn.debian.org/svn/debian-med/trunk/packages/velvet/trunk/debian
+  uscan
+  tar --strip-components=1 -xvzf ../*.orig.tar.gz
+ 
+  #Check the version of the tarball you downloaded and set the version of this package appropriately.
+  #In this case I had velvet_1.1.05.tgz
+  #Note that 'dch' will launch an editor for you to add any comments about the build.
+  dch -v 1.1.05-custom1
+ 
+  #See what build dependencies are required and then install them manually
+  dpkg-checkbuilddeps
+  sudo apt-get install cdbs debhelper zlib1g-dev help2man
+  
+  #Check patches.  Sometimes, a patch fails and needs to be fixed manually.
+  quilt push -a   #Try to apply all Debian-specific patches.  If this works, skip to next part
+  quilt push -f   #There is an error, so force the final patch
+  cat *.rej       #Examine conflicts
+  nano Makefile   #Manually fix missing -lm -lz in Makefile
+  quilt refresh   #Commit new version
+  rm *.rej        #And clean up rejects file
+ 
+  #Now you can build the whole thing to get your .deb
+  debuild -i -us -uc -b
+ 
+  #And it is ready to install
+  sudo dpkg -i ../velvet_1.1.05-custom1_amd64.deb
+ }}}
+ 
+ The above is the most direct route to building a fairly simple package for your own use, but if you want to get more involved in package building or contribute fixes back to Debian Med then it is suggested to read the available documentation, and especially the [[http://debian-med.alioth.debian.org/docs/policy.html|Debian Med group policy]].  This package happens to be in the Subversion repository but the package you want may be in Git, and also note that some tools may be part of a larger download and will be packaged under that name.  The trickiest bit in the above build was that the final patch failed because the small issue it addressed had been fixed by the newer upstream but in a slightly different way.  Sorting this out it required a little knowledge of the [[http://pkg-perl.alioth.debian.org/howto/quilt.html|quilt]] patch system, Makefile syntax, and linking to standard shared libraries (libz, libm) in order to get a working Makefile.  Quilt was then refreshed to capture the necessary modifications as a patch file.  The aim is to get to the point where 'debuild' runs successfully as this does all the work to make the DEB, and will complain if there are outstanding dependency or patch issues.
+ 
+ If you attempt a package build and get compilation failures, even when all dependencies are satisfied, then people on the [[http://lists.debian.org/debian-med/|Debian Med mailing list]] should be able to help.
+ 
+ == Q. I succeeded in making a package compile; how do I contribute my build for others to use? ==
+ 
+ A. Debian Med does not directly distribute binary packages, so if you wanted to share the binary .deb you would have to do so yourself.  If you are an Ubuntu user the [[https://help.launchpad.net/Packaging/PPA|PPA facility on Launchpad]] may be what you are looking for.
+ 
+ If you have fixed an error with a package, for example to make it compatible with a new version of the upstream release, then the package maintainer will appreciate your help.  In the example above I tested building a newer version of Velvet and fixed one of the patch files to work with this new version.  I can generate a patch file that captures my updates like so:
+ 
+ {{{#!highlight bash
+ ( cd debian && svn diff ) > /tmp/my_changes_to_velvet.patch
+ }}}
+ 
+ Now I can contact the maintainer of the package (as listed in the debian/control file or revealed by dpkg -s etc.) directly, copying the message to the [[http://lists.debian.org/debian-med/|mailing list]].  If I explain my changes clearly the maintainer will see that they are correct and a push the changes through to Debian.  These can go into Debian Sid immediately filter through to Debian Testing and the Ubuntu development release in short order.
+ 

