See www.zabbix.com for the official Zabbix site.

Appeal against public upstream packaging

From Zabbix.org
Jump to: navigation, search

An appeal against packaging outside of distributions

This is a draft document.

Every distribution is different. Even a new release may introduce major changes. Most distributions have their distinct guidelines of how things must be packaged, and for good reasons. It is virtually impossible to follow all those changes and would probably require a full-time job for all possible target distributions. With a distribution packagers, you'll usually be ready for future releases.

If you are concerned about your packages, work with distribution packagers or become the distribution packager. That's the best approach.

Why developers usually should not publish their own packages

Fragmentation

Having various sources of packages creates fragmentation:

 A: ICMP ping doesn't seem to work with 2.0 on CentOS 6!
 B: Where did you get your packages from?
 A: xy.domain.com
 B: Oh, these packages have a known flaw, but EPEL packages do it differently/don't have that problem in the first place.
 Sadly migrating is a bit tricky, because it's not possible to design for such a migration.
 C: Oh, they all suck! Let's use mine from evil.hack.us.
 A: No, now I'm confused. I'll just compile it myself.

Which leads to the general discussion about why packaging is useful.

Duplicated efforts

It also duplicates efforts, with a worse result in the long term:

  • A packaging problem is reported on the Zabbix bugtracker and is never solved in any distribution packages
  • A packaging problem is discovered and must be fixed in multiple places, instead of one
  • A packaging problem is discovered and fixed in only one place, creating fragmentation
  • A packaging problem is discovered and fixed in different manners, creating fragmentation
  • You have to take care of all the work usually done by distribution packagers or face the consequences
  • You can run into all the kinds of problems distribution packagers know very well and that usually don't happen to them anymore
  • Why would distribution packagers even consider to invest a minute of their spare time in packaging, to "rival" against a package from the developers, that can hardly meet all distribution requirements? Though it's not always visible, packagers often invest a lot of time and track down a number of issues doing so.

More work for developers

Distribution packagers will often know, if there are relevant changes. For instance, different versions of Fedora ship different versions of fping, accepting different options. Also, if a Zabbix user reports a bug he sees within Zabbix, and that is attributed to Fedora's netsnmp, chances are good this will be tracked and solved. Now consider if Zabbix employees have to do all that:

  1. A user reports on the Zabbix bug tracker that something is wrong with SNMP on Fedora
  2. A Zabbix employee has to set up a current Fedora box and test
  3. After some work, he finds netsnmp is broken in Fedora
  4. He creates a bug in Fedora's tracker on netsnmp
  5. He needs to monitor this bug and make sure it gets solved properly
  6. He will possibly test it afterwards and leave a message on the Zabbix tracker, it's solved

With a bug reported on the Fedora bugtracker in the first place, this bug will probably never hit the developers, sparing you from all that.

User acceptance

Some people also wouldn't bother to install software from third-party repositories. There's a certain risk involved:

  • Overwriting files
  • Inconsistent behaviour (Not adhering to File Hierarchy Standard, automatically starting some daemons, ...)
  • Legal (Only free software is allowed in some distributions, like Debian or Fedora)
  • No suitable update path

Availability

Independent software vendor repositories tend to not be as well mirrored as distribution repos. You can, of course, easily mitigate this by mirroring their repo inside your own infrastructure.

But ...

... PostgreSQL has packages too!

PostgreSQL packages are crafted by the same people that package it for distributions.

... distributions don't package all the features of Zabbix!

That's usually for a good reason, for instance:

  • Non-free license -- ZBX-4800
  • A general mess -- ZBX-4987
  • License incompatible
  • No source code available for a component -- ZBX-4794
  • Component doesn't work in this distribution for some reason (SQLite frontend in Fedora/RHEL, because of how PHP is built)

... distribution packagers are slow!

Work with them! Manpower is limited. In the case of Zabbix 2.0, we needed major restructuring for Fedora/EPEL:

  • Have Zabbix ready for systemd (thus EL 7) and init scripts in one spec file (i. e. RPM cooking recipe)
  • Use separate system users for agent and server/proxy for security -- https://support.zabbix.com/browse/ZBX-4916
  • Have a working upgrade path from 1.8 without silently breaking Zabbix
  • Consider SELinux
  • Start the discussions on the Java gateway, see above
  • Move away from conflicting sub-packages and use Debian alternatives to switch between database implementations
  • Test and remove the non-working SQLite frontend/server

Often enough, packages are actually created on the day of release. There's an incubation for updates in EPEL though, that allows for testing: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

While this period is generally 2 weeks, you can skip it by giving positive feedback.

EPEL also has a strong policy of which kind of updates are allowed. See above link for details.

... our customers need trustworthy packages!

Zabbix makes use of at least 2 community packages: fping and iksemel. Will the customer trust in these community packages?

If a customer really needs packages "made from" Zabbix employees, simply distribute the EPEL package and sign it with your personal signature. RPM packages can have multiple signatures a customer can verify. If you need to make customer-specific changes, you're totally free, but don't make these packages available to the general public.