Yeah, as Seth writes, it'll be a fine line. The other thing is
infrastructure: right now we have one bro-plugins repository, which is
pulled into aux/ but nothing in there is built automatically. I see
three options:
(1) Leave as it is; i.e., not build any plugins by default.
(2) Select some plugins in bro-plugins that build automatically
with Bro.
(3) Split bro-plugins into two repositories. One set would build
with Bro, the other not. We'd need to decide if both would be
pulled into the Bro source tree, or not.
Sounds we don't want (1), but I'm undecided between (2) and (3).
Opinions?
For both (2) and (3) we'll need to integrate the selected plugins into
Bro's build process, including passing through configure options.
Maybe a minor downside to (3) would be it’s less smooth of a transition if you ever wanted to promote/demote a plugin — involves moving code across repo as well as changing configure/CMake glue whereas (2) I’m guessing just involves the later with plugin code staying unchanged/unmoved.
Maybe try approach (2) first as it seems simpler, then find out along the way what improvements are needed.
Yeah, I can see that. I wondering if we could find a mechanism to
automatically hook selected plugins into the Bro build without
changing anythign there. Maybe they'd ship with a configure hook that
the main configure searches all plugins for; or something to that
effect.
What I don't like about this is that eventually these should all be pushed into external plugins so I feel like we should just keep the amount of work minimal for now. We're just fighting against the non-existence of a package manager right now.
I like plan #2 the best for now too. Although I guess without doing the configure option thing, it would turn things like geoip into a required dependency.
> Maybe they'd ship with a configure hook that the main configure
> searches all plugins for; or something to that effect.
We're just fighting against the non-existence of a package manager
right now.
True, but I don't see us having one for the next release, and I'd
rather have a solid mechanism in place that we remove later, than just
some hack for which we don't know how long it will have to last.
Seems the consensus is that we want some plugins compile along with
Bro by default. I have a few smaller things on my list for the plugin
stuff that I still want to do, I'll add this to it and mull over it a
bit more then. (Btw, another piece here is getting plugins that
compile with Bro to also install with the global "make install").
I like plan #2 the best for now too. Although I guess without doing
the configure option thing, it would turn things like geoip into a
required dependency.
It could still be an optional dependency; the plugin just wouldn't be
compiled if it doesn't find geoip.
