Bug#663101: review of the upstream foreman debian package
Firstly, apologies for the slow reply - I've been on vacation, and
catching up with work :)
I'm really happy to discuss getting Foreman (and it's other packages,
such as the proxy and the installer) into Debian - that would be
My replies to your questions, and my own thoughts, are in-line...
On 17 April 2014 01:44, Antoine Beaupré <firstname.lastname@example.org> wrote:
> First off, the foreman-installer completely overwrites existing apache
> configuration files, which is contrary to Debian Policy, c. 7.6.1:
The installer makes no changes to anything when the package is installed:
# dpkg -L foreman-installer | grep /etc/apache2 | wc -l
It also has no postinst or preinst scripts which could modify Apache
Changes to the Apache configuration only happen when the installer is
executed by the user (which is intended, since Foreman's default
configuration is to use Apache).
> Also, apt-get install foreman just fails:
I can't reproduce this I'm afraid. On a fresh Wheezy box:
root@wheezy934:~# apt-get install foreman
The following NEW packages will be installed:
binutils build-essential bundler cpp cpp-4.7 dpkg-dev fakeroot
foreman foreman-proxy g++ g++-4.7 gcc gcc-4.7
libalgorithm-merge-perl libc-dev-bin libc6-dev libdpkg-perl
libfile-fcntllock-perl libgomp1 libgssrpc4 libitm1 libkadm5clnt-mit8
libmpc2 libmpfr4 libquadmath0
libstdc++6-4.7-dev libtimedate-perl linux-libc-dev make manpages-dev
patch rake ruby-dev ruby-rack
ruby-rack-protection ruby-rkerberos ruby-sinatra ruby-tilt
ruby1.9.1-dev rubygems-integration unzip zip
Fetched 76.0 MB in 43s (1,750 kB/s)
Setting up foreman (9999-wheezy+scratchbuild+201405011056) ...
foreman not configured to start. Please edit /etc/default/foreman to enable.
Seems fine. This was using our nightly repo, but the same successful
result is obtained with the 1.4.x packages.
> Also, the underlying packages do not seem to cleanup properly after
> root@puppet0:/etc# apt-get purge foreman-postgresql foreman
Testing this, it seems the Gemfile.lock is being left behind. I've
filed a bug on the Foreman tracker to address this.
> ... which basically means it will totally fail to install on wheezy,
> which still has rails 2.3.
> There is a lot of work to do.
> There's probably way more stuff i'm missing here.
I've put these 3 comments together, because (in my opinion) this is
the largest problem in getting Foreman upstream. Currently there are
approximately 140 gems vendored in ~foreman/vendor/cache (including
Rails 3.2.17). Every single one of these would need to become a new
package in order to satisfy Debian's Ruby Packaging guidelines (as I
understand it), and I do not have time to do this (which is why they
This problem is compounded by versioning problems with popular gems
(such as Rails) - Foreman currently *requires* at least Rails 3.2.8,
and is likely to move to Rails 4 soon. Many other gem dependencies
move very quickly (often for security patches) so we'd need to make
sure we were being repsonsive to that, as well.
Until we have a clear plan of how to handle these gem dependencies,
getting the Foreman package itself upstream seems impossible (unless I
misunderstood, and Debian policy does indeed permit vendoring of gems)
> Having it installable on a simple wheezy environment would be a start. I
> also strongly encourage you to run the package through "lintian" to make
> sure it's properly built.
As demonstrated above, the packages are installable. Without further
debugging, I can't speculate on why you hit the Rails version issue,
but that's the first time I've seen that error - and the wheezy
packages are well tested.
I've checked lintian and there's nothing massively serious, mostly a
few ruby-script-but-no-ruby-dep errors which can probably be easily
fixed at some point.
> Looking forward to see Foreman in Debian...
Likewise, if we can figure out what to do with the gems :) I'm always
available on Freenode if you want to discuss in real-time (nick:
gwmngilfen, channels: #theforeman, #theforeman-dev)