1. Move each into a a separate repository on the zeek/ GitHub
2. Similar, but to avoid cluttering zeek/, create a new GitHub
I'm thinking (2). Technically, either one can likely be made to work,
but (1) has a slight downside in terms of hurting a primitive
browsability use-case: I imagine people want to simply scroll through
a list of packages on GH, and the existing non-packages in zeek/ would
distract from that goal.
3. Put them all into a single mono-repository (e.g.,
zeek/standard-packages), i.e., treat them a one package.
The shortcoming of that structure is the lack of customizability. If
a user only wants a specific set of functionality, or wants to avoid a
set of scripts due to intrinsic overhead/conflict, it's better if
they're able to start from blank slate and add only the pieces they
4. Do (1) or (2), and additionally create "zeek-standard-packages"
that's full of submodules pointing to them (and also to
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.
Between those, (5) may fit more naturally -- zkg may already be fit to
handle "meta packages" via simple package metadata dependency
configuration. Plus, that's a similar pattern to other package
management environments AFAIK.
This, from my point of view, it would be neat to have a way to still
easily install a rather large set of packages (potentially nearly
everything that is in policy at the moment) and run test on them.
Agree that type of integration test is helpful -- may find conflicts /
bad-interactions / versioning-issues that way.
Sometimes we perform changes to Zeek
that change a lot of the test baselines - especially when we touch
something that affects connection-ID hashing, or the order of elements
in hashmaps. These cases might now require an update to the test-cases
in a large number of packages. It would be neat to have an easy way to
Might be a chance to go another direction and revamp the test-writing
guidelines/patterns (or provide internal config options that help
produce "canonical" outputs) such that less test-cases are fragile to
these kinds of widespread, low-level changes in the first place. E.g.
if the order of elements in hashmaps is not defined, it's the fault of
any given test-case that chose to rely on a specific order being
produced. Or if an irrelevant change in UID breaks a test, the test
either needs to canonify or exclude UID from its pass/fail criteria.
I think if we want to do this, we need to have a better story for
versioning than we, at the moment, have with zkg. To expand on this - at
the moment the policy scripts just work with the version of Zeek that we
distribute them with.
I see the current story for versioning as this: package metadata
advertises Zeek version compatibility, zkg knows how to enforce that
dependency, and package authors are left in control of deciding their
compatibility requirements and implementing them (likely via @if or
Once scripts that used to get distributed along with Zeek become
independent packages, I agree they should start abiding by that story,
but I'm not sure if there were any further ideas to help minimize the
overall maintenance burden/friction associated with this new
It would be nice if, afterwards, it would still be possible to install a
working set of a script for the running version of Zeek. Meaning that -
if someone happens to run a version of Zeek that is 12 months out of
date - they should probably get the version of the policy script that is
known to work with this version of Zeek and where the tests pass with
this version of Zeek.
Seems like a couple distinct questions:
* What's the LTS policy for packages? It can be made different/longer
than LTS policy for Zeek-proper if that's desirable. But if a
12-month LTS cycle is decided for packages, too, any extra effort
spect to support older Zeeks sends mixed messages.
* How to obtain an aggregate set of packages that were validated with
Zeek X.Y.Z: seems like a job for the (meta)package dependency metadata
to point directly to specific package versions (in the realm of git