[Debian-pan-maintainers] Debian Packaging

PICCA Frederic-Emmanuel frederic-emmanuel.picca at synchrotron-soleil.fr
Thu Dec 17 13:15:07 GMT 2015


   > Hi Frederic,

   Hello Zibi and others
   
   > Here at Alba, we are selecting the operating system for our new
     subsystems (currently being built) as well as eventual update of
     the old openSUSE 11.1. The strongest candidates are Debian 8 and
     Leap 42.1 > (openSUSE).
   
   
   ok
   
   > In the selection process we are deeply analyzing the packaging
     and package management aspects. So we will give a try to package
     ourselves our control software. We have already tried building
     packages for the > python projects, using the distutils module,
     but we also wanted to give a try to the "Right Way" Debian
     packaging standards [1].
   
   ok
   
   
   > The best would be to reuse as much as possible the controls and
     scientific stack provided by Debian. But most probably we will be
     also affected by the following cases:

   > 1. Patch the package provided by Debian e.g. Tango and rebuild it.

   The purpose of the packaging is to be able to rebuild everything
   from sources. So this should not be an issue.

   > 2. Take the package provided by Debian, update the upstream and
     rebuild it e.g. Taurus or Sardana releases from the develop
     branch.

   What you want is a way to integrate the Debian packaging into the
   upstream repository.  It is possible to create a dedicated branch
   where you have only the debian directory. This way you can merge
   this branch with your develop branch and build a package from here.

   You can read the DEP-14[14] in order to understand how to name the
   git branch and howto do the tagging.

   I would recommend to store the packaging repository on the Debian
   infrastructure (alioth[15]) in order for other institutes to
   contribut to the packaging. This is an important point for
   collaboration in the long term.

   Indeed the generation of a new developpement package should be as
   easy as possible.

   > 3. Create our custom packages from scratch e.g. beamline 22 GUI.

   For softwares that you do not expect to distribute via Debian , you
   can put directly the debian directory in yout repository and build
   it with a simple `debuild` command.

   
   > We plan to follow the "Right Way" guides. Just in case, we are
     asking if you advice some other steps or have some hints for us.
   
   First the Debian wiki[1], is the right place if you look for
   information up to date (or not ;).

   A general advice if you want to enjoye your Debian experience.
   Package everythings.
   You have a proprietary sdk, -> package it
   You need a specific kernel module for this equipement. -> package it also.
   never ever allow someone to install as root via 
   make install, python setup.py install etc...[17]

   If this is the case your upgrade will become really painfull.

   Use a software in order to automatize your computer administration.
   puppet, ansible, chef... and indeed propellor[16] ;)

   
   Packaging
   =========
   
   In the case of languages which already have some generic packaging
   tools there is a dedicated page[2] For general purpose packaging
   you can look at here [3][4][5]. Since you are using lot's of
   python, you should read the library packaging page[6] and also the
   one dedicated to the python application[7] even if from my point of
   view it is less interesting.
   If your software is available via pip and not in Debian, just use
   python-stdeb, in order to create automatically a debian package for
   a module.
   
   Build
   =====
   
   you have plenty of tool in order to build your packages.here a list
   of usefull packages.
   
   pbuilder, cowbuilder, sbuild, deb-o-matic[8],
   mini-buildd[9]. jenkins pluging[10], aptly[11]
   
   I personally use sbuild which is the tool used officially by debian
   in order to build there packages.  They build in a schroot in order
   to have a clean environment during the build.  But I do not need to
   setup a build system and maintain a dedicated repository.  I most
   of the time just need to use Debian infrastructure and upload into
   the debian-backports

   A nice post from a Debian guy which describe the workflow in order
   to use and maintain a local repository for a corporate.[12] Very
   intersting and explain if I remmeber corectly the versionning
   scheme and how to deal with a testing distribution in order to test
   packages and the packages used in production.

   You can find a network of deb-o-matic instance which can be used in
   order to build packages [13]. This is nice because you do not need
   to maintain the infrastructure by yourself.

   If you need more informations do not hesitate to ask.

   Frédéric

   [1] https://wiki.debian.org/
   [2] https://wiki.debian.org/AutomaticPackagingTools
   [3] https://wiki.debian.org/Packaging
   [4] https://wiki.debian.org/IntroDebianPackaging
   [5] https://raphaelhertzog.com/debian-packaging/
   [6] https://wiki.debian.org/Python/LibraryStyleGuide
   [7] https://wiki.debian.org/Python/AppStyleGuide
   [8] https://debomatic.github.io/
   [9] http://mini-buildd.installiert.net/
   [10] http://jenkins-debian-glue.org/getting_started/manual/
   [11] http://www.aptly.info/
   [12] http://vincent.bernat.im/en/blog/2014-local-apt-repositories.html
   [13] http://debomatic-amd64.debian.net/
   [14] http://dep.debian.net/deps/dep14/
   [15] https://alioth.debian.org/
   [16] https://propellor.branchable.com/
   [17] https://wiki.debian.org/DontBreakDebian


please keep debian-pan-maintainers in CC to have a public archive of this discussion.
thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ALBALogoSignatureSmall.jpg
Type: image/jpeg
Size: 8485 bytes
Desc: http://www.albasynchrotron.es/.jpg
URL: <http://alioth-lists.debian.net/pipermail/debian-pan-maintainers/attachments/20151217/b560e47a/attachment.jpg>


More information about the Debian-pan-maintainers mailing list