[Debian-pan-maintainers] [ctgensoft] Debian Packaging

Wed Dec 23 08:19:23 GMT 2015

Wow Fred, ...a  million thanks!

I am sorry I didn't reply before. I was working from home and quite 
busy. I started looking at your links, but it will take some time to 
process so much info, so we will come back with questions after the 
holidays, 

Thanks!

On Thu 17 December 2015 13:15:07 PICCA Frederic-Emmanuel wrote:
>    > 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

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual at cells.es
 Phone: +34 93 592 4428
+----------------------------------------------------+