> On Jul 25, 2016, at 10:31 PM, Matthias Vallentin <[email protected]> wrote: > >> Right now, packages don’t get downloaded via the submodule, they are >> cloned directly from the package’s full git URL (which git just >> happens to encoded within the submodule). >> >> So this means only packages a user is interested in end up getting >> downloaded. > > I'm not 100% following. Isn't every package recorded as submodule?
Every package within a package source is recorded as a git submodule and that recording happens at the time the package author registers their package with a source. The bro-pkg client itself makes no changes to submodules. > Is there any use case where you would do a submodule update? Depends on who “you” refers to: - a regular bro-pkg user: no, they don’t need to be aware that submodules are used - a package author: no, they only care that submodules are used when they do the one-time registration process to add their package to a source - the bro-pkg developer/maintainer: not currently, but that’s maybe an implementation detail. I don’t currently ever update submodules and instead clone packages directly via their full git URL to a separate location because I think that’s the more robust implementation. - some other entity that does periodic analysis on all packages (e.g. web frontend): I’d probably expect them to not be using bro-pkg at all, but they clone a package source and do recursive submodule updates on it as the easiest way of downloading the latest versions of everything. > Or are the > packages just recorded there instead of recording them in a separate file? Right, using git submodules isn’t a requirement for the bro-pkg client to work, we could make up a different file/format for registering packages. But maybe submodules do provide some convenience for the last use case mentioned above. > I think "known" is also ambiguous, because it doesn't clearly convey > the local aspect. How about just saying "filters installed packages”? Not all subcategories of “list” are working with just the locally “installed” packages. E.g. “list all” is looking at both installed packages (local git repos) and not-installed packages (remote git repos, but we know about them because they are registered with a source). How about this description: “The ‘list’ command outputs a list of packages that match a given category” > maybe add an underscore, e.g., script_path and plugin_path? Yeah, can do that. And maybe “dir” is more meaningful than “path” since the later may mean file or directory? - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
