RFC: debian: device server packaging

Are there any packaging guidelines for the device servers (where to install the binaries, configs, etc in a FHS compliant way)?

Maybe having something like dh-make-tango - which could generate "standard" packages from pogo based device servers?

Any hint is appreciated.
Hello, if I remember correctly some preliminary work was done into pogo in order to generate autotools project files.
Once we have these files it should be easy to generate a proper Debian package for a Device.
But I do not know the status of this.

for the RFC part, you are right something should be done in order to facilitate the packaging of all tango devices.

The main difference for now with the default install on Debian is:

All the devices meant to be started from starter are installed under
/usr/lib/tango and not under /usr/bin

the purpose is to avoid polluting the /usr/bin/ directory with hundreds of binaries.
a lot like git sub commandes. But we miss the uniq command which allow to start these devices.

something like

tango_admin start <device>|<deviceserver>|<device instance> <parameter> etc…

it is possible to start a device but you need to gives the full path
/usr/lib/tango/<device-server> <params>

Maybe the community should decide about this problem.

I would says thaht if device should be installed into an unusual location this should be deal correctly in the build system and exposed as a variable in the tango.pc file

something like

tangodevicebindir=${prefix}/lib/tango

This way it should be possible to install the devices even in another place like /usr/bin ;)

Hello Fred,

Just to mention that within Pogo, there is still the feature of generating autotools source distribution for the Tango class.
However, because we never get any questions/remarks about this feature, we guess that it has not been very heavily used!

Cheers

Emmanuel
Hello Tangoers,
At ALBA we will start packaging for Debian and we would like to reopen the discussion on where the Device Servers should be located inside linux.
Fred proposed good ideas:

All the devices meant to be started from starter are installed under
/usr/lib/tango and not under /usr/bin

It does not follow the FHS compliant way, but it could be adopted by the Tango community.
And if it is done in the future, the Starter could be adapted to assume it.

Manu said:

Just to mention that within Pogo, there is still the feature of generating autotools source distribution for the Tango class.

We do not understand where it matches with the packaging, but for sure following a convention
for compilation and binary generation is a "must" also for us. We tried to use as much as possible the pogo preferences.

We know that several institutes are using "standard" packages. So, for opening the discussion again I launch some questions:

We would like to know how are you proceeding in your institutes regarding the location of your DS (on linux).
What about python DS? Where do you install their python modules? We should follow the FHS
or it should be under a special directory such as $tangodevicebindir e.g. /usr/lib/tango/python2.7.

Many thanks for your hints!

Best,
Carlos on behalf of CTGensoft
cfalcon
We would like to know how are you proceeding in your institutes regarding the location of your DS (on linux).
Hi Carlos,
we use /usr/lib/tango also for ThomX, to keep our DS at the same place.

cfalcon
What about python DS? Where do you install their python modules? We should follow the FHS
or it should be under a special directory such as $tangodevicebindir e.g. /usr/lib/tango/python2.7.
We actually do not have a lot of python DS and to test them, they have not been placed into a specific directory.

It is true that the path /usr/lib/tango is a bit confusing for the first use of TANGO.

As it is proposed, an environment variable could be good way to define the default DS directory, and it could possibly be defined by default following the FHS. Could /usr/bin/tango be a solution for this default configuration? (a [symbolic] link could be added for retrocompatibility)
This way, one could define a different path if needed.

By curiosity, does anyone know the reasons which first led to use /usr/lib/tango as path for some DS ?
- Philippe
Edited 7 years ago
philippeg
cfalcon
What about python DS? Where do you install their python modules? We should follow the FHS
or it should be under a special directory such as $tangodevicebindir e.g. /usr/lib/tango/python2.7.

It is true that it should be possible to use private directory for python modules

I think that the best reference is there

https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs

Indeed you should find plenty of information on the debian-python mailing list.
https://lists.debian.org/debian-python/

philippeg
We actually do not have a lot of python DS and to test them, they have not been placed into a specific directory.

Fred
It is true that the path /usr/lib/tango is a bit confusing for the first use of TANGO.

As it is proposed, an environment variable could be good way to define the default DS directory, and it could possibly be defined by default following the FHS. Could /usr/bin/tango be a solution for this default configuration? (a [symbolic] link could be added for retrocompatibility)
This way, one could define a different path if needed.

By curiosity, does anyone know the reasons which first led to use /usr/lib/tango as path for some DS ?



Here an important information for the environment variable when you expect to package something :)

https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9

for the /usr/lib/tango, I must confess, that It is a personnal decision I took looking after 'git' when I was the almost only user of the Debian package. I saw that ten/hundreds of devices are availables with no namespace which allows to know what is a device or what is not in when using the completion in my terminal.

Now I can go to the /usr/lib/tango directory and have the list of all the devices. These devices are meant to be started by the starter so no need to put all this under /usr/bin.

Nevertheless, if the community want to change this I will follow the decision.
To my opinion, tango_admin should be available in the /usr/bin directory instead of /usr/lib/tango
Hi,

At HZG we are using maven to build debian packages for our servers. Maybe this will be interesting for some of you: here is an example of such server
Within Pogo, you can generate a python package structure.
With that, the installation is like any other python package, just :
python setup.py install
Then it goes where the default python package installation folder is.
It also generates a script for launching directly the device server from any console.
You have to use the pythonHL binding in order to have the option to generate the python package structure.

I think it's a good idea to simplify the packaging and the sharing of the python DS.
The generated egg are prefixed with tangods_
We could then have maybe a pypi repository for "ultra" easy installation.

With this structure, it's also easy to generate a linux packages or a msi setup for the windows guys.
setup.py build_msi

Hi SGara_Nexeya,
Within Pogo, you can generate a python package structure.
With that, the installation is like any other python package, just :

python setup.py install

Then it goes where the default python package installation folder is.
It also generates a script for launching directly the device server from any console.

Setuptools is wonderful and simplify the life, but by default it treats the DS like python modules and we think that most of them are not. We should stablish a convention following any python-policy.

By the way, I will merge the Python and PythonHL Pogo options, I think it is very useful and the option to generate the setup file is optional. There is any reason for not do it?

Best,
Carlos
cfalcon
Hi SGara_Nexeya,
Within Pogo, you can generate a python package structure.
With that, the installation is like any other python package, just :

python setup.py install

Then it goes where the default python package installation folder is.
It also generates a script for launching directly the device server from any console.

Setuptools is wonderful and simplify the life, but by default it treats the DS like python modules and we think that most of them are not. We should stablish a convention following any python-policy.

By the way, I will merge the Python and PythonHL Pogo options, I think it is very useful and the option to generate the setup file is optional. There is any reason for not do it?

Best,
Carlos

Hi,

The reason for not doing it was that some time, we just want a simple python file, and you knwo people like having the choice.
I think that the future is with PythonHL.
 
Register or login to create to post a reply.