On Mon, Aug 24, 2020 at 6:43 AM Robin Sommer <ro...@corelight.com> 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 <zeek-dev@lists.zeek.org> 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
