I like (2) for cleanliness. I think some people would be fine with one large package, but in other cases, you may want the ability to easily enable/disable various standard scripts. Probably not wanting to maintain the same script in multiple places, I think that eliminates (3). Towards, (4) & (5) and iven the number of standard scripts, there should be an easy way to distinguish them from other packages when doing a 'zkg list'. Maybe that's just done via a tag or in the naming scheme.
-Dop On Mon, Aug 24, 2020 at 8:43 AM Robin Sommer <ro...@corelight.com> wrote: > Looking for some thoughts here. One of the items on the roadmap for > 4.0 is moving scripts that currently live in policy/ over into Zeek > packages. The goals here are to (1) facilitate maintaining & testing > them independently of Zeek releases; and (2) come to a more flexible > notion of "default scripts" that can incorporate community-maintained > packages as well. This is tracked by issue > https://github.com/zeek/zeek/issues/414, including a 1st pass over the > existing policy scripts to understand what should/can be moved. > (Thanks, Vlad!) > > Before we can begin working on this, we need to figure out how to > organize this new world. One particular question is where the moved > packages will live. I see the following options so far: > > 1. Move each into a a separate repository on the zeek/ GitHub > account. > > 2. Similar, but to avoid cluttering zeek/, create a new GitHub > organization "zeek-packages". > > 3. Put them all into a single mono-repository (e.g., > zeek/standard-packages), i.e., treat them a one package. > > 4. Do (1) or (2), and additionally create "zeek-standard-packages" > that's full of submodules pointing to them (and also to > community packages). > > 5. Do (1) or (2), and teach zkg to understand "collections" of > packages that can be installed/managed as a group, defined > through some meta data somewhere. > > Along with all of this comes a question of how to make it easy for > people to install a set of default packages now that these won't come > with Zeek itself anymore. Some of the schemes above make that easier > than others. > > Thoughts/opinions/more ideas? > > Robin > > -- > Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com > _______________________________________________ > zeek-dev mailing list -- zeek-dev@lists.zeek.org > To unsubscribe send an email to zeek-dev-le...@lists.zeek.org >
_______________________________________________ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
