Rework / rethink the way we are dealing with plugins (and their dependencies)

[vStone]

One way would be to fall back to native packages. We are currently using this approach but currently people will have to create the native packages themselves. I have opened up https://issues.jenkins-ci.org/browse/INFRA-1498 on the jenkins side to maybe help us out with this.

Alternative approaches could be:

• Using an plugin API and talk to the jenkins master.
• If jenkins does not want to package for us:
  ** Provide a mirror of our own (hosted somewhere)
  ** Provide people with an easy set of tools to deal with this themselves. We could either enhance FPM or wrap around FPM to help with this.

[vStone]

This was once (several years ago) already attempted in #12

[bjakubiak]

I use https://github.com/roidelapluie/Jenkins-Plugins-RPM to build set of rpms based on json from jenkins update center. It works surprisingly well for 5 commit repository. It uses docker to build packages. Doesn't need much more effort to put those rpms into existing jenkins rpm repository.

[vStone]

I (almost) have a similar gem (that does a little bit more) which in turn uses fpm. Either way, it would be nice to have a 'voxpupuli' solution for this :)

[bjakubiak]

When you have packages that resolve dependencies, it is easy to use puppet's Package resource.

[camservo]

It would be kinda cool to have some sort of meta-packages also. I've ended up just listing every plugin that jenkins installs in it's "recommended plugins" for my local configuration.