request for installable packge that could be seeded into deb/rpm repos

[ezavesky]

Request for a packaged binary version that correctly enumerates (and installs) required libraries. With the availability of modern CI services and other resources, it would be great if ssl-vision could be built and distributed through a common deb package. There appear to be some control files in the tree already, but it's not clear how and when they are used. Below are proposed acceptance criterion for this issue.

• a packaged deb file for at least Ubuntu 12.X and Ubuntu 14.X
  • both of these Ubuntu images are available as CI environments within travis
  • proposed solution: utilization of the CPack functionality available in CMake (current build driver)
• a stable build indicator (and integrator) for new development PR's and commits so that the burden on the project maintainer is reduced (and acceptance time is minimized)
  • proposed solution: Introduction of a .travis.yml file and update of CMake utilities to use the packaging utilities already available
  • typically with modern CI's, this functionality will come for free, but it does require a few github authorizations from the project manager

[ezavesky]

Not wanting to cloud the issue itself, efforts to bring ssl-vision into Travis are underway at a forked integration branch. Before bringing these changes to ssl-vision, the excessive/experimental commits (is there an easier way with a network-distributed service?) will be pruned.

[g3force]

I tried introducing such installable packages in other applications in the past and my experience is: It is not worse the effort. Some reasons:

• You will never have a package for all distributions
• You have to refactor the way, configuration files are stored, because there is no unique working directory anymore. As you still want to have the possibility to run ssl-vision from a Repo, you would need a way to conditionally place config files.
• it creates even more distance to the code, discouraging people to contribute

[ezavesky]

Sure, solving everyone's requirements simultaneously may not be feasible. The main objectives of a CI process were (a) automatic building of a reference that would immediately throw bugs (and offer a route for a test harness) and (b) let beginners get started with some package if they wanted to. Towards your objections on (b) was the ability to jump in with a VM and get something running.

I do acknowledge though that 'something' may be nothing really because there isn't really a 'simulation' mode that the environment currently supports.