> On Jun 9, 2016, at 5:32 PM, Siwek, Jon wrote:
>
> I like the “packages” + “package-manager” combo that Johanna suggests.
I like that too. It feels nice and clean.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
> I like the “packages” + “package-manager” combo that Johanna suggests.
+1
Matthias
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> On Jun 9, 2016, at 3:29 PM, Matthias Vallentin wrote:
>
> I'm not sure if I understand the -community suffix. The client bro-pkg
> makes sense to me. But the first association I have with
> bro-pkg-community is a community-version of bro-pkg (i.e., the client).
Was mostly
On 9 Jun 2016, at 13:29, Matthias Vallentin wrote:
>> I see benefits in two separate repos:
>
> Yep.
>
>> client: bro-pkg
>> community packages: bro-pkg-community
>
> I'm not sure if I understand the -community suffix. The client bro-pkg
> makes sense to me. But the first association I
> I see benefits in two separate repos:
Yep.
> client: bro-pkg
> community packages: bro-pkg-community
I'm not sure if I understand the -community suffix. The client bro-pkg
makes sense to me. But the first association I have with
bro-pkg-community is a community-version of bro-pkg
> > Do you equate one package with one container, or does the plural
> > "packages" signify something more collection-ish?
>
> I see them as one to one.
Okay, that's what I was thinking as well.
Matthias
___
bro-dev mailing list
bro-dev@bro.org
> On Jun 8, 2016, at 5:32 PM, Matthias Vallentin wrote:
>
> One question though: what is the top-level container name?
package
> Do you equate
> one package with one container, or does the plural "packages" signify
> something more collection-ish?
I see them as one to
Sounds good.
On Wed, Jun 08, 2016 at 19:13 +, you wrote:
> git repo name: bro-pkg
Do we maybe need need two repositories, one for the client and for the
packages?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
> project name: Bro Package Manager
> client name: bro-pkg
> git repo name: bro-pkg
> design spec/proposal: use Robin's/Johanna’s
> top-level container name: packages
> changes to existing naming conventions: none
Looks good to me.
One question though: what is the top-level container name? Do
> On Jun 7, 2016, at 12:55 PM, Siwek, Jon wrote:
>
> I’d appreciate if anyone would think a bit about whether “package” still
> actually makes sense to use in the current context and doesn’t actually need
> a rename.
I can always repose this later if I’m struggling w/
> On Jun 7, 2016, at 9:32 AM, Azoff, Justin S wrote:
>
> So, the way this could work is that '$TOOL install foo' could both 'install'
> and 'enable' 'foo' and '$TOOL disable foo' could disable it without removing
> it.
Yeah, that’s what I was thinking people would
On Tue, Jun 07, 2016 at 18:29 +, you wrote:
> echo @load bro-pkgs.bro >> $BRO_INSTALL_DIR/site/local.bro
Yeah, ok, I can see that. Tieing it to local.bro takes care of my
primary concern, that way it takes effect only when running through
BroControl (or loading local.bro expliclty).
> On Jun 6, 2016, at 10:46 PM, Robin Sommer wrote:
>
> So sounds like this proposal is something you can agree with?
Yes.
>
> On Tue, Jun 07, 2016 at 02:01 +, you wrote:
>
>> So scripts do not autoload, but plugins do?
>
> Thinking more about that I would answer: yes.
On Tue, Jun 07, 2016 at 04:52 +, you wrote:
> Only difference is I don’t think the client needs the plural.
Yep, I meant bro-pkg, the plural was just a typo.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev
> On Jun 6, 2016, at 2:50 PM, Robin Sommer wrote:
>
> - At install time ("cban install" or whatever) gets copied into
> a subdirectory at a global location ("cp -rp
> /"). Uninstallation means removing that
> installation directory.
One thing to think about is a
> On Jun 6, 2016, at 9:46 PM, Robin Sommer wrote:
>
>>
>> That all looks consistent except part (2) ends up pointing people
>> toward existing docs/examples that reference “package” but with a
>> different meaning. I'd need a decision to be made about how/whether
>> to change
So sounds like this proposal is something you can agree with?
On Tue, Jun 07, 2016 at 02:01 +, you wrote:
> So scripts do not autoload, but plugins do?
Thinking more about that I would answer: yes. Going back to the
principle of least surprise, this is how it is now as well: scripts
need
> On Jun 6, 2016, at 4:55 PM, Robin Sommer wrote:
>
> On Mon, Jun 06, 2016 at 21:08 +, you wrote:
>
>> Similar to Daniel’s question, is there a one time setup the user does
>> or they need to modify local.bro every time they install a new
>> container?
>
> In this case I
On Mon, Jun 06, 2016 at 21:08 +, you wrote:
> Similar to Daniel’s question, is there a one time setup the user does
> or they need to modify local.bro every time they install a new
> container?
In this case I was thinking modify local.bro. That said, I remember
your "load"/"unload" now,
> On Jun 6, 2016, at 1:50 PM, Robin Sommer wrote:
>
> - For shipping scripts:
>
>- We simply add to Bro's BROPATH. That means one
> can now put "@load " into local.bro and Bro will look for
> a __load__.bro inside the top-level container directory. That
>
On Mon, Jun 06, 2016 at 14:14 -0500, you wrote:
> Could you clarify what you mean by BRO_PLUGIN_PATH here?
I mean we magically extend the BRO_PLUGIN_PATH so that Bro will find
it there. No manual configuration, CBAN will take care of pointing Bro
to the right place inside the plugin's
On 06/06/2016 01:50 PM, Robin Sommer wrote:
> - For shipping binary plugins:
>
> - Through meta information, we let the author specify a build
>command to build all their binary stuff, such as "./configure &&
>make && make test". The command line client runs that command
>
So Johanna and I just white-boarded a somewhat more generic approach
that we believe would work well to cover the various use-cases without
hardcoding much in terms of structure at all.
The brief summary is that we would allow people to specify how to set
BROPATH and BRO_PLUGIN_PATH, and how to
23 matches
Mail list logo