> On Sep 20, 2016, at 2:32 PM, Robin Sommer <ro...@icir.org> wrote:
> 
> On Tue, Sep 20, 2016 at 14:35 +0000, you wrote:
> 
>> 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.
> 
> What would that do for updates? Say I've unloaded a package, but I'm
> still updating it? That shouldn't enable it, so would it do that
> implicit "load" only on first install?

Yeah, I imagine it detecting whether a given package in a bundle is already 
installed.  If it is, then just install/overwrite it without changing its 
“loaded” status.  If not, then install and also load.

>> I think bro-pkg currently works fine even if you don’t have a local Bro 
>> installation?
> 
> I was thinking that it needs bro-config. Is that only for "autoconfig"
> to set up the right paths?

Yes, bro-config is only necessary for the “autoconfig” command.

> If so, then maybe we can add an option to
> "autoconfig" to setup (and create) local paths for this
> working-without-a-Bro mode?

Currently for that use-case, I’d say “just don’t run autoconfig, the default 
paths are sufficient”.  On the source machine, packages can get installed 
anywhere.  On the destination machine, the unbundling process will relocate 
everything to the correct paths.  In other words, the installation paths of a 
bundle are not hardcoded within it.

But if we want to keep the bro-pkg initial setup procedure more consistent, I 
can have autoconfig first ask a question: “Will you be using this system to 
create package bundles?”

If no, proceed with the current autoconfig logic (use bro-config to setup 
paths).

If yes, still proceed with autoconfig if bro-config is available, else no-op.

- Jon

_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Reply via email to