4 ms·
Have a recommendation for what we should be doing? More than happy to update how we package to make things easier or more idiomatic
by pauldix 11y ago
Have a recommendation for what we should be doing? More than happy to update how we package to make things easier or more idiomatic
- dozzie 11y ago1. Split all the above-mentioned steps to separate scripts or makefile targets. It's ridiculous to mix them; how are people supposed to build InfluxDB inside networks that don't have access to internet? 2. Learn how to build RPMs and DEBs the proper way (Debian source package, SRPM) instead of cutting corners with FPM. It fails to include dependencies, and full description, for instance, or to mark files as configuration. And yes, your binaries do have dependencies. Also, your DEB metadata is broken, according to lintian. 3. Learn where to put which files in Linux. LSB wasn't agreed on for nothing. 4. Rewrite your post-install script to something that fits your target distributions' conventions. This most probably means two scripts, for Red Hat and for Debian. For instance, under Debian your packages create service user that doesn't fit the rest of the system (UID above 500, home under /home, usable shell).
- justinsb 11y agoI've wanted to create (deb) packages in the past, but found a large number of conflicting instructions on the "right way". Is there an approach / howto-doc you would recommend?
- jpgvm 11y agoThe right way is to provide a debian directory with the appropriate packaging metadata. Use git-buildpackage and associated tools (git-dch etc) to build the packages natively (or allow others to build for their Debian based distros).
- justinsb 11y agoThanks, but it's still not obvious to me what to do. Looking at this: https://wiki.debian.org/PackagingWithGit https://wiki.debian.org/PackagingWithGit, git-buildpackage documentation seems to suggest either creating a separate branch, or packaging tarballs, both of which seem different to what you're suggesting where I just create a debian directory. Do you have a different document or an example repo with the debian/ directory? This is why I've resorted to FPM in the past - the deb tools seem so simple, and I'm sure they are simple for people that have done it before, but the documentation for FPM is much more direct and thus people (such as myself) use it, even though we know it's not "right".
- dozzie 11y agoJust like the large number of conflicting instructions for building iptables firewall, none of which got it how to write a set of rules and instead focuses on how to write a set of commands. One just needs to apply common sense instead of blindly follow somebody's recipe. But why not just use the introduction from the official documentation? https://wiki.debian.org/IntroDebianPackaging https://wiki.debian.org/IntroDebianPackaging
- justinsb 11y agoI find that introduction is intended for people packaging software that other people have written, where upstream creates a tarball. What FPM nails is the use-case where a developer wants to package their own software. Obviously I could take on the role of upstream, publish .tar.gz files, and then take on the role of packager and consume those, but I think you can understand at that point why FPM looks so attractive! You obviously know this area well: a link to software you have written and packaged would be greatly appreciated.
- XorNot 11y agoIt'd also be nice to have official systemd service files. With Debian 8 out there its basically necessary now.