> On Sep 19, 2016, at 6:27 PM, Robin Sommer <ro...@icir.org> wrote:
> @Jon: Do you think this would be doable that way?
Yeah, looks viable.
> - I’m not quite sure if the bundle should contain just the packages
> themselves or further bro-pkg state as well, such as which packages
> are currently loaded. Right now I’m learning towards saying “just
> the packages”; that would basically treat bundles just as a
> transport mechanism to get packages over to another box. The actual
> Bro machines would still keep control over which packages to
> actually load, etc.
Yeah, I think that’s generally how it would be also. Though, maybe since the
default behavior of the “install” command is to automatically do a subsequent
“load” it makes sense to automatically do loads after “unbundle” as well. It
would then be up to user whether they actually “@load packages” in the target
machines local.bro or just pick and choose, so they still have complete control
> - As it is described above, Step 1 would require having a local Bro
> installation into which packages get installed before they can be
> bundled up. It would be nice to have a mode where bro-pkg can
> operate without having a Bro around at all, just downloading
> packages locally somewhere for bundling them up. I could also see
> offering an even simpler mode where one simply lists packages to
> bundle on the command-line: “bro-pkg bundle <pkg1> <pkg2> <pkg3>”.
> That would be particularly useful with configuration management
> systems I think.
I think bro-pkg currently works fine even if you don’t have a local Bro
If you build plugins, you’d need Bro source code, but don’t actually need it
installed. Then on the target machine, “unbundle” just unpacks into whatever
bro-pkg paths are configured for script_dir/plugin_dir.
bro-dev mailing list