Uncertain solutions in packaging buildbot 0.8.1
Dear mentors,
Some time ago I mentioned about some solutions in buildbot package I'd
like to discuss since I'm not sure if they are completely right.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/b/buildbot
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/b/buildbot/buildbot_0.8.1-1.dsc
My changelog contains the following information:
* New upstream version.
Closes: #587313.
- Fix homepage in debian/control
Closes: #587314.
- Fix CSS stylesheet is not set for index.html.
Closes: #576284.
* Switch to dpkg-source 3.0 (quilt) format
* New manual pages for buildbot and buildslave binaries.
* Split package into two according to new project structure.
* Configuration is now stored in apache-like manner for better management.
* Switch to /bin/sh interpreter in init-scripts
Here are the things I'm not sure:
1. Changelog.
The new upstream version fixes all bugs available in Debian BTS.
Should I mention all of these bugs like I did or should I just set a
list of bugs closed by new upstream without any details?
2. Naming.
The upstream separated client and server code and now server binaries
and the python package itself are still called `buildbot', and the
client binaries and python package are called `buildslave'. However I
used `buildbot-master' and `buildbot-slave' for naming packages and
system users. The previous version of the package had one system user
called `buildbot' however upstream documentation does not recommend
such configuration. I could also use one user for both packages as
before but I'm not sure how should postrm script work to purge the
package (i.e. what to do with buildbot instances inside buildbot home
directory). Should I use debconf and ask user during package
installation?
3. Init scripts.
Prevoius package used bash arrays defined in /etc/default/buildbot to
list managed buildbot instances. I used apache-like configuration for
both buildbot-master in /etc/buildbot/masters-(available|enabled) and
buildbot-slave in /etc/buildbot/slaves-(available|enabled) with almost
the same configuration options as were in previous package. However
the init-scripts themselves grew dramatically. I also admit that such
configuration still needs the buildbot configuration files in
/etc/buildbot to be valid shell scripts since they are sourced by
init-scripts which is definitely a bad idea. For now I don't know how
to solve this problem properly. Also there is no strict mechanism to
detect buildbot startup failure and some failure cases are not
detected automatically.
4. Unified configuration.
I tried to make some unified configuration for all system managed
buildbot instances, e.g. use common places to store pids
(/var/run/buildbot-*) and logs (/var/log/buildbot-*). I didn't like
the way to store all logs from different buildbot instances (which
especially have been running by different users) and found the
solution in screen package. It uses username as a folder to store
files for every user. For example, if we have buildbot master instance
called `testbot' which is run by `test' user, we'll have PID-file in
/var/run/buildbot-master/test/testbot.pid and log file in
/var/log/buildbot-master/test/testbot.log. I should mention that
upstream version 0.8.1 had some issues concerning logging
(http://buildbot.net/trac/ticket/973) which is fixed in the next
release so I added this fix as a patch until the next release.
5. `#! /usr/bin/env python' in scripts generated by setuptools.
Curently this is fixed with `sed -i'. I wonder if there is a better solution.
I really would like to hear your opinions on this. Thanks in advance.
--
with best regards, Andriy Senkovych
Reply to: