[PKG-Openstack-devel] Packaging OpenStack command line clients

[Thomas Goirand]

On 03/07/2017 09:16 PM, David Rabel wrote:
> On 04.03.2017 01:50, Allison Randal wrote:
>> On 03/01/2017 06:31 AM, David Rabel wrote:
>>> More on the python-openstackclient. As I understand it has some
>>> dependencies on project-specific clients. So those would be interesting,
>>> too.
>>
>> Okay, great! So, the best place for you to start is to checkout out the
>> git repository for Debian packaging of python-openstackclient. The clone
>> path is provided at the bottom of the page:
>>
>> http://git.openstack.org/cgit/openstack/deb-python-openstackclient
>>
>> Once you've checked it out, switch to the branch named "debian/newton",
>> and then take a look at the contents of the top-level directory named
>> "debian/" to start getting familiar with the types of files involved in
>> Debian packaging.
> 
> I am familiar with some debian packaging basics. I started packaging a
> few months ago.
> 
> I still have a few questions:
> 
> Why is there a debian/newton branch? I thought, the command line clients
> have a different release cycle than the main openstack components.

What's true, is that clients should always be able to be backward
compatible (ie: the last version of a client should be able to work with
any release of OpenStack). Though on each release of OpenStack, the
versions are increasing, and clients gets release. In reality, *we do*
need such branching, also because clients are tight to specific versions
of oslo libs and such.

> postrm and prerm do nearly the same thing. Wouldn't one of them be enough?

It's needed. It'd be long to explain why, but it is. These are generated
using "pkgos-alternative-bin".

> I don't understand all of the adjustments to debian/rules. Where can I
> get information on pkgos-.. commands?

I believe there's man pages associated to each of these commands. If
not, just read the script itself (it's in the openstack-pkg-tools
package, in /usr/bin), it's often short and easy to read. If you don't
understand what one script does, let me know, and I'll explain + write
the appropriate man page.

> Why are there commands that are not supposed to run?

A quick example will make you understand easily. We use "dh" (ie: the
debhelper sequencer), which by default does *ALL*. For a command line
script, we don't need to install icons in the desktop application menu.
Therefore, we don't need to run dh_installmenu, which would waste build
time. So, I decided it'd be nice to just override it, so it's not run,
and then build time is faster. This way, we got the best of both worlds
(ie: with or without dh).

I hope this helps,
Cheers,

Thomas Goirand (zigo)