[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