> 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 over loading/unloading. > - 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 installation? 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. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
