[pkg-uWSGI-devel] Bug#1076420: uwsgi: move away from cdbs - status update

[Alexandre Rossi]

Hi,

> Thanks for your work on migrating away from CDBS.  I have stared at it
> many times, and know that it must have been quite a challenge.
> 
> Unfortunately, I don't like the changes. :-(

No problem with that I wanted to start the discussion constructively. The good
news is that now I have a good idea of what's needed to do that.

> One problem is that you did the transition as one big git commit
> (when the fixup patches assumably gets merged).  That makes the change
> difficult to follow, in case it turns out that some corner case is not
> working as intended, and there is a need to understand what was meant in
> more details with each detail of the change.

I started with small changes, but moving away from cdbs requires from my
experiments a complete overhaul of d/rules, and that makes making small
commits really difficult.

> The bigger problem, however, is that your transition replaces CDBS with
> another even more unique chunk of code, written in Python that I will
> not be comfortable maintaining.

Although I think string manipulation involved in this packaging is better
(as in more readable and less prone to mistakes) expressed in python
than in GNU make, I understand what you mean.

uwsgi packaging as we need it shall carry out at least the following
functions.

* produce debian packages

  current implementation     : cdbs
  my choice of implementation: debhelper

* build uwsgi-core

  current implementation     : GNU make
  my choice of implementation: GNU make

* define the list of plugins to try to build and associated parameters

  current implementation     : GNU make
  my choice of implementation: python
  alternative                : GNU make, or perl, conf file (JSON or other)

* determine the list of plugins to build according to target arch

  current implementation     : GNU make
  my choice of implementation: python
  alternative                : GNU make, or perl

* determine the list of plugins to build according to plugin flavours

  current implementation     : GNU make
  my choice of implementation: python
  alternative                : GNU make, or perl

* build plugin flavours

  This involves for each plugin to manage a source plugin name, the
  target file according to flavour, and specific build command or
  environment. This also involves producing symlinks and specific
  manpages for a subset of the plugins.

  current implementation     : GNU make
  my choice of implementation: python
  alternative                : GNU make, or perl

* templating for dh files and scripts for apache2 modules binary packages

  current implementation     : GNU make
  my choice of implementation: python
  alternative                : GNU make, or perl

* templating for dh files and scripts for plugin binary packages

  current implementation     : GNU make
  my choice of implementation: python
  alternative                : GNU make, or perl

* ease checking consistency of plugin archs vs build dep archs

  current implementation     : shell script + sed
  my choice of implementation: python
  alternative                : GNU make, or perl

All this is currently implemented in GNU make syntax, so this is doable to
move to debhelper and not introduce some helper script. I'll try to
come up with something. However, I still think that the handling of the
plugin build configuration would be easier to maintain with a more capable
language than GNU make.

Seeking your opinion on these ideas,

Alex