bro-devel package?

Development
1

There are a couple of cases where I think it’d be useful to have a bro-devel package – a package that I can install on a system, and then be able to build plugins against Bro. (This is the same model as other *-devel packages, such as openssl, libpcap, etc.)

Right now, if I compile Bro from source, run make install, I can’t build a package with what’s in /usr/local – Bro needs the entire source tree, since the required headers are not present in /usr/local.

I’m curious how people are dealing with this issue, and if anyone has thoughts on whether this would be useful, and if so, what it would take to build such a package.

Thanks,

–Vlad

2

Well that’s s great question!

Right now my spec for building plugins downloads entire bro tree and does some cmake plugin to avoid waiting for the tree to build.

3

I ran into this issue in two places: on our infrastructure and working out how to support bro as a language on travis-ci.

For our installations I worked around it by just building packages that contain bro plus all the plugins I need and dump the entire thing into a single RPM. This works ok for me, but would never work for something like debian that is probably trying to figure out how to package some of the bro plugins.

This also doesn't work for adding bro support for travis.. the OBS RPMs come close.. we can install those plus bro-pkg, but any packages that need to be built against bro won't compile.

4

There are a couple of cases where I think it'd be useful to have a bro-devel
package -- a package that I can install on a system, and then be able to
build plugins against Bro. (This is the same model as other *-devel
packages, such as openssl, libpcap, etc.)

Yes, I think it's useful and something that should be done. It was
fairly low on my list of things to try to do before 2.6. Related:

https://bro-tracker.atlassian.net/browse/BIT-1922

I'm curious how people are dealing with this issue, and if anyone has
thoughts on whether this would be useful, and if so, what it would take to
build such a package.

My guess as to what needs to be done:

* separate bifcl into its own submodule: I think this should be easy
* install Bro's headers: at least I think that's all that we need to
do on our end, it's also a bit of an open question as to whether we
just install them all for now until we get a more organized API or can
get away with a smaller subset
* update the plugin CMake/configure skeletons and/or bro-config to be
able to make use of the above two points

- Jon