On Thu, Jul 28, 2016 at 17:52 +0000, you wrote:
> I think still allowing package sources to be structured in a directory > hierarchy is more intuitive to navigate and maybe less intimidating to > modify than a single file as the source grows over time. And I’m > already using INI format in 2 other places, so seems fine to apply > here, too. Yep, agree with both. That also makes merging pull requests easy / contained. > So a proposed structure of a package source: Looks good to me. > the CMake summary output. Let me know which is preferred. I’m a bit > in favor of auto-installing the python dependencies into Bro’s install > prefix. I also prefer auto-installation, unless there's a reasonable risk that it could interfere with already installed versions of those packets, not sure? > The hierarchy isn’t strictly required to use GitHub usernames. > Generally could be "$author_name/$package_name”, where the most common > case is for $author to be a GitHub user name. A domain name, > company/organization name, or any string to help identify the author > would work. Ok, we probably need to write down our policy somewhere what we do/expect for the default source. > Agree about changing “package-manager” to “bro-package-manager”, but > do you also mean to get rid of the “lib” subdir? No, I didn't, sorry for the confusion. I was just too lazy to type the full path again, should have inserted 3 dots to make that clear. > Tried to do this in the Overview/README’s “Installation” section. I > think reorganizing that in smaller sections with bullet points to > follow and re-labeling it as “quick-start guide” may help. Ack. Robin -- Robin Sommer * ICSI/LBNL * [email protected] * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
