Debian Policy compliance

[jlecour]

Hi,

This issue has a sibling, in the Kibana issue tracker.
It is about improving the Logstash package to be more Debian Policy compliant.

For Logstash, the main issue is that it is install in /opt instead of /var/lib and the binaries are in a subdirectory of the main install directory instead of /usr/bin.

As I've said in the Kibana issue, I'm very grateful of the immense work and want to do as much as I can to help make things better.

[purbon]

Good morning, as you could see in #5341 there has been an efforto to make the package more standarize, however I'm not sure what are the benefits of following debian policy ? would you be so nice to enumerate them?

thanks a lot.

[suyograo]

@jlecour For 5.0.0, here's our directory structure which mirrors ES: https://www.elastic.co/guide/en/logstash/5.0/dir-layout.html

[jlecour]

@purbon When packaging a software for a specific system, it's considered best practice and good citizenship to conform to the "local" policy. That way, sysadmin who install the package are not surprised by unusual configuration of log/conf/bin/… paths It also helps standard tooling support the package, for example logrotate, pid supervision, binary protections, configuration backup…

@suyograo I was suspecting that this work would be underway for v5 but I didn't search enough. Thanks for pointing to this guide.

[suyograo]

Thank you @jlecour! As this breaks compatiblity, we can only do this for 5.0 (a major release).

[untergeek]

@jlecour As an organization, we do not want to have to maintain separate documentation for each distribution: Debian uses these paths, Redhat these, SuSE these paths, and so on. It's tedious for users to have to crawl through extra documentation, and tedious for package builders/maintainers to have to maintain extra options and packages.

In spite of it not conforming to the "local" policy, is easier to maintain if the file system tree is the same on all packaged systems.

[jlecour]

@untergeek I understand the "it's easier" argument, but I think it's a bit odd here.

For one, as an organization you've apparently already done most of the work to adapt to the ecosystem you package for, hence the specific documentation I've been pointed to.

Then, if "easier" is the motto, why bother making packages then? When you make packages, it's for helping people to use your software on their environment, and taking advantages of "local" customs.
Otherwise, using tarballs is good enough ; the maintainer (individual or organization) develops it's software and the user takes cares of adapting it to its environment. It's OK in many situations, but it doesn't look like what Elastic has been doing.
I honestly salute the great work done by the team, and that work is more and more appreciated by the users of the ELK stack, pleased with ease of install, use and maintenance.