Fpm: Missing `--rpm-systemd` flag?

[mjulian]

There are flags for --rpm-init, --deb-init, and --deb-systemd, but --rpm-systemd seems to be missing from this list.

[jordansissel]

I'd honestly like to remove all of these in favor of somehow integrating the new pleaserun support into this, though I'm not sure how to do it just yet.

I am +1 in favor of adding --rpm-systemd until we have the above integration availble.

[ndobbs]

I too would like to +1 to include an --rpm-systemd option to FPM. I need this functionality and wondered why there was a --deb-systemd and nothing for RPM.

Thanks for all of your work with the project.

[monokal]

+1 - Is this on the roadmap anywhere? I've not looked through the source but I imagine most of it will be a duplicate of --deb-systemd.

[dmjio]

@jordansissel, Hello! Have there been any updates on this? Would be glad to help in any way I can.

[josegonzalez]

There aren't any updates, but pull requests are welcome :)

[unsaturated]

Your situation may vary, however, the following is a workaround if you're generating a package from a directory:

1. Convert your directory to a deb package and use --deb-systemd
2. Convert that deb package to rpm (e.g. fpm -s deb -t rpm *.deb)
3. Inspect the rpm and you should see the .service file in /lib/systemd/system

Thank you to all the contributors on fpm. Great work!

[mohd-akram]

I've opened pull request #1405 for this.

[s1na]

@jordansissel Could you please consider keeping the init and systemd flags (along with merging #1045), instead of deprecating them in favor of pleaserun?

This way it would be possible to use custom systemd units or sysv services, which is helpful when using FPM to ship a multi-platform package.

[jordansissel]

I am OK with your proposal to keep the flags.

On Tue, Oct 17, 2017 at 3:05 PM Sina Mahmoodi [e-mail]
wrote:

@jordansissel https://github.com/jordansissel Could you please consider
keeping the init and systemd flags (along with merging #1045
https://github.com/jordansissel/fpm/pull/1405), instead of deprecating
them in favor of pleaserun?

This way it would be possible to use custom systemd units or sysv
services, which is helpful when using FPM to ship a multi-platform package.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/jordansissel/fpm/issues/1163#issuecomment-337224909,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIC6mt6ZAlYt-f4fOQ2BFV2UE6y_kAvks5stKYegaJpZM4JSKE7
.

[perfecto25]

for RPM pkg workaround,

1. place your systemd startup script into the dir that you will be packaging as RPM,
2. run FPM with -s dir, provide a --after-install script that will move your systemd startup from the install dir to /etc/systemd/system
3. when you install the RPM, the after install script moves the system script over to the right location,

for example,

packaging scriipt,

echo "....CREATING Bitbucket RPM from stage dir"
/usr/local/bin/fpm -s dir -t rpm \
--after-install additionals/after-install \
-C stage/ \
--name $app \
--version ${version} \
--iteration "1" \
--workdir $(pwd) \
--architecture x86_64 \
--maintainer "Atlassian" \
--description "Atlassian $app" \
--url "www.atlassian.com" \
--package $(pwd)/RPM/${app}-${version}-1.x86_64.rpm \
-d $db_name

"after-install" script

# move systemd startup
mv /opt/atlassian/$app/$app.service /etc/systemd/system/
systemctl enable $app.service

its hacky but it works.

[mohd-akram]

@jordansissel As you plan to keep the flags, would you consider merging my PR for --rpm-systemd?

[jordansissel]

@mohd-akram yes indeed! I will follow up with you on https://github.com/jordansissel/fpm/pull/1405

[ericrange]

why not merged yet? i need this!!! :(

[Varriount]

@ericrange In the meantime, you can (ab)use the --config-files option to mark a systemd unit file as a config file, and include. The unit file can either be in a relative path mirroring it's root destination (./etc/systemd/system/file) or an absolute path (/etc/systemd/system/file).

The advantage of this method over the above methods, is that the file will be tracked by RPM and be removed when the package is removed - no scripts required.