-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make it easier to target different distributions? #1826
Comments
I like this idea. I'm not entirely sure what the interface would look like (that is, how would a user say "Target Ubuntu 20.04" to the fpm cli). In working on pleaserun, I found some platform detections to be fairly straight forward while also allowing folks to be explicit, such as "Target Upstart 0.65" or something. Documenting the per-platform specifics would be a good place to start. The fpm documentation files (in
Speaking of init systems, I don't know how often this part of fpm is used, but fpm can create a single package that targets many init systems at the same time. This is done with the
Basically, a "pleaserun" package generates an install script which detects the target system (when the package is installed) and installs the appropriate files necessary to run the service (/etc/init.d, systemd, upstart, etc). |
@Dieterbe If you're most interested in init/servicei stuff, I think we're closer to a solution given my above comment about pleaserun and fpm's support for it. Let me know what you think :) The idea with It might be desirable to make fpm produce a single package that contains both the application and the service management pieces provided by For a similar example, Logstash includes the pleaserun library in the release packages in order to run
|
Seems like the fpm+pleaserun combo is a good step forward over just fpm where one has to provide the right init/run scripts and know how to include them. The main considerations on my mind:
By moving the magic from "runtime on target system" to package generation time, packages (and their generation) become also more testable and verifiable. Of course, an advantage of the current approach is the "one distro package works on many versions [of that distro]".
Is this in line with best practices ? Of which distributions? On Debian, for example the redis packages seem to include the service along with the server (but separate out admin tools), seems the redis server also includes the init scripts on centOS I suspect most people would prefer a single package solution, which also seems simpler. But maybe i'm missing something. |
Hello! First of all, thanks Jordan and other contributors for this fantastic tool. It certainly has helped me.
My main issue is keeping up with the various updates to linux distributions (debian, ubuntu, centos, etc) and their expectations and requirements. Sometimes they change init systems for example, and while fpm provides flags to help me include files to target certain init systems, the onus is still on me (and many other fpm users?) to keep up with the distributions release notes to find out if i should update my fpm commands/flags to accommodate new versions.
I have two suggestions:
I'm making this post to gauge interest from others for either of these solutions, or perhaps i'm missing something?
thanks,
Dieter
The text was updated successfully, but these errors were encountered: