On Mon, Aug 24, 2020 at 6:43 AM Robin Sommer wrote:
> 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".
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
want.
> 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.
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.
On Mon, Aug 24, 2020 at 11:49 AM Johanna Amann via zeek-dev
wrote:
> 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
> perform this.
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
#if directives).
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
requirement.
> 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
tags/branches/commits, etc.).
- Jon
___
zeek-dev mailing list -- zeek-dev@lists.zeek.org
To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
