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.
+ 

_______________________________________________
debian-med-commit mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-commit

Reply via email to