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
