Long term, we'll probably have a "smart" post-install that will choose
the correct service (systemd, etc) to install based on the platform
doing the installation, not the platform creating the package :)
Adds dependencies on pleaserun and upgrades clamp to suit.
Example using the defaults in pleaserun:
# Create a package called 'example-service' that installs a service named 'example'
% bin/fpm -s pleaserun -t rpm -n example-service --pleaserun-name example =logger hello world
No platform selected. Autodetecting... {:platform=>"systemd", :version=>"default", :level=>:warn}
Writing file {:destination=>"/tmp/package-pleaserun-staging20160513-12576-1ozurnf/lib/systemd/system/example.service"}
Writing install actions. You will want to run this script to properly activate your service on the target host {:path=>"/tmp/package-pleaserun-staging20160513-12576-1ozurnf/install_actions.sh"}
Created package {:path=>"example-service-1.0-1.x86_64.rpm"}
# ^^ The above service will execute "logger hello world"
# What's in our rpm?
% rpm -qlp example-service-1.0-1.x86_64.rpm
/lib/systemd/system/example.service
# What about any post-install steps?
% rpm -qp example-service-1.0-1.x86_64.rpm --scripts
postinstall scriptlet (using /bin/sh):
systemctl --system daemon-reload
# Install it.
% sudo rpm -ivh example-service-1.0-1.x86_64.rpm
# Start it.
% sudo systemctl start example
# Check the logs!
% sudo tail -n1 /var/log/messages
May 13 03:32:55 localhost root: hello world
Example choosing 'sysv' as the platform:
% bin/fpm -s pleaserun -t rpm -n example-service --pleaserun-platform sysv --pleaserun-name example =logger hello world
Writing file
{:destination=>"/tmp/package-pleaserun-staging20160513-13675-xae6xd/etc/init.d/example"}
Writing file
{:destination=>"/tmp/package-pleaserun-staging20160513-13675-xae6xd/etc/default/example"}
Created package {:path=>"example-service-1.0-1.x86_64.rpm"}
% rpm -qlp example-service-1.0-1.x86_64.rpm
/etc/default/example
/etc/init.d/example
Controlling where output is sent is necessary if you want to use fpm as
a library rather just a command line tool.
This is implemented using the open4 rubygem because the open3 that ships
with ruby 1.8.7's stdlib doesn't set $? so you can't get the exit
status of the process.
The negative side effect of this change is that it introduces buffering,
so you don't get stderr and stdout in the order in which they were
output. And the output isn't sent to the terminal until the process has
completed, which is annoying. Perhaps it's possible to do something
with threads to solve this problem.
Jordan Sissel
Elan Ruusamäe
Diego Martins
Matt Hoffman
Paweł Tomulik
Pete Fritchman
Elan Ruusamäe
Paul Stengel
Pranay Kanwar
Tray Torrance
Mike Williams
Matt Blair
Ronald Holshausen
Jay Buffington