Hacker News new | past | comments | ask | show | jobs | submit login

We package our software for CentOS, Debian, Ubuntu, and have occasionally supported a few others. We never even considered targeting the LSB. It is so much simpler to target the defaults on the system, build for the top three or four or five distros (which actually ends up working on several spin off systems, by virtue of similarity), and when problems arise we know we're not the only ones running into it because we are using the same libs as the rest of the system.

The idea of one package for all distros is cute but not at all realistic. And it isn't pleasant for the end user, who wants everything in their native package manager and things to be configured in the same ways as everything else.

LSB was a well-meaning idea, but it doesn't actually do anything to improve openness or interoperability.




It is possible to build one binary that run on all reasonably popular distributions, even for quite complex software; there is just pretty much no documentation on how to set up a build environment to do so (there is no "GNU/Linux SDK").

A project I was familiar with some years ago used essentially a NFS mount containing a subset of a 4 year old "enterprise distro" and then built with GCC --sysroot plus some vars like PATH, PKG_CONFIG_PATH etc set appropriately.

One of the problems is, beyond the few things listed in LSB (so it's not entirely useless!) it's not at all obvious what libraries you can expect to be on the system in an ABI compatible way - if you want to use something as unstable as OpenSSL you have to bundle it.


Well 1 thing of LSB does help in 1 case: init.d return codes, very important with some HA tools.


We support and manage all of the major init systems (initscripts, systemd, Upstart, BSD, etc.) so we don't care about that (or we do, but the software already has configuration and code for all of the possibilities).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: