CBAN naming

Development
61

One thing to think about is a distinction between installed vs. enabled for scripts and plugins.

A good system that I have used is how debian sets things up for the apache configuration.

When you install the apache package they setup things like mods-available and mods-enabled directories:

root@b28027aa3d70:/# ls -l /etc/apache2/mods-available/|head
total 524
-rw-r--r-- 1 root root 100 Oct 24 2015 access_compat.load
-rw-r--r-- 1 root root 377 Oct 24 2015 actions.conf
-rw-r--r-- 1 root root 66 Oct 24 2015 actions.load
-rw-r--r-- 1 root root 843 Oct 24 2015 alias.conf
-rw-r--r-- 1 root root 62 Oct 24 2015 alias.load

root@b28027aa3d70:/# ls -l /etc/apache2/mods-enabled/|head
total 0
lrwxrwxrwx 1 root root 36 Jun 7 13:46 access_compat.load -> ../mods-available/access_compat.load
lrwxrwxrwx 1 root root 28 Jun 7 13:46 alias.conf -> ../mods-available/alias.conf
lrwxrwxrwx 1 root root 28 Jun 7 13:46 alias.load -> ../mods-available/alias.load
lrwxrwxrwx 1 root root 33 Jun 7 13:46 auth_basic.load -> ../mods-available/auth_basic.load

if I install the libapache2-mod-php5 package I end up with it enabled automatically:

root@b28027aa3d70:/# ls -l /etc/apache2/mods-*/php*
-rw-r--r-- 1 root root 865 Apr 27 11:42 /etc/apache2/mods-available/php5.conf
-rw-r--r-- 1 root root 59 Apr 27 11:42 /etc/apache2/mods-available/php5.load
lrwxrwxrwx 1 root root 27 Jun 7 13:48 /etc/apache2/mods-enabled/php5.conf -> ../mods-available/php5.conf
lrwxrwxrwx 1 root root 27 Jun 7 13:48 /etc/apache2/mods-enabled/php5.load -> ../mods-available/php5.load

but then can easily disable it without uninstalling it:

root@b28027aa3d70:/# a2dismod php5
Module php5 disabled.
To activate the new configuration, you need to run:
  service apache2 restart
root@b28027aa3d70:/# ls -l /etc/apache2/mods-*/php*
-rw-r--r-- 1 root root 865 Apr 27 11:42 /etc/apache2/mods-available/php5.conf
-rw-r--r-- 1 root root 59 Apr 27 11:42 /etc/apache2/mods-available/php5.load

This is just hooked up in the apache config using

IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf

They also do this available/enabled setup for standalone conf files and sites(vhost configs)

The nice thing about this system is that the base installation can include standard modules that are present but not enabled by default:

root@b28027aa3d70:/# ls -l /etc/apache2/mods-*/cgi.*
-rw-r--r-- 1 root root 58 Oct 24 2015 /etc/apache2/mods-available/cgi.load
root@b28027aa3d70:/# a2enmod cgi
root@b28027aa3d70:/# ls -l /etc/apache2/mods-*/cgi.*
-rw-r--r-- 1 root root 58 Oct 24 2015 /etc/apache2/mods-available/cgi.load
lrwxrwxrwx 1 root root 26 Jun 7 13:56 /etc/apache2/mods-enabled/cgi.load -> ../mods-available/cgi.load

The directory/symlink thing is just one implementation, automatically editing a special .bro file and adding/removing lines would work too.

So, the way this could work is that '$TOOL install foo' could both 'install' and 'enable' 'foo' and '$TOOL disable foo' could disable it without removing it.

62

Yep, I meant bro-pkg, the plural was just a typo.

Robin

63

So sounds like this proposal is something you can agree with?

Yes.

So scripts do not autoload, but plugins do?

Thinking more about that I would answer: yes.

Ack.

And if the process isn’t the same in both cases, is that also in
conflict w/ the goal of a developer being able to promote a
script-only thing into a binary plugin without users noticing?

Isn't that more about moving some functionality, like bifs? I don't
think a plugin would replace the scripts completely.

Yeah, I’m not seeing specific problems thinking about it more now.

Ok, then let's rename "package" in the current docs. I propose
"module" as the replacement: it's not quite right regarding the
language's module concept but close enough I would say.

I’d appreciate if anyone would think a bit about whether “package” still actually makes sense to use in the current context and doesn’t actually need a rename.

My point about a package being something that can both require metadata and not require metadata might be clear enough to explain based on context? E.g. From Bro/BroControl’s point of a view packages don’t require metadata. From the package manager tool’s perspective, packages require metadata.

Seems like obvious/expected behavior from user’s view and not ambiguous?

- Jon

64

So, the way this could work is that '$TOOL install foo' could both 'install' and 'enable' 'foo' and '$TOOL disable foo' could disable it without removing it.

Yeah, that’s what I was thinking people would want/expect.

The directory/symlink thing is just one implementation, automatically editing a special .bro file and adding/removing lines would work too.

Part of the process of installing the tool could be

  echo @load bro-pkgs.bro >> $BRO_INSTALL_DIR/site/local.bro

Then the bro-pkgs.bro script just needs to be in BROPATH and the tool would automatically add/remove entries from it. That special script can be maintained in the same place where the tool is maintaining all its installed packages.

- Jon

65

Yeah, ok, I can see that. Tieing it to local.bro takes care of my
primary concern, that way it takes effect only when running through
BroControl (or loading local.bro expliclty).

Robin

66

I can always repose this later if I’m struggling w/ using it in the docs, but I have my head wrapped around the various contexts it can be used in now that the design is changed, so I’m not blocked on it.

I’d like to move forward w/ the following unless there’s still objections, open questions, or I misunderstood general consensus:

project name: Bro Package Manager
client name: bro-pkg
git repo name: bro-pkg
design spec/proposal: use Robin's/Johanna’s
top-level container name: packages
changes to existing naming conventions: none

- Jon

67

project name: Bro Package Manager
client name: bro-pkg
git repo name: bro-pkg
design spec/proposal: use Robin's/Johanna’s
top-level container name: packages
changes to existing naming conventions: none

Looks good to me.

One question though: what is the top-level container name? Do you equate
one package with one container, or does the plural "packages" signify
something more collection-ish?

    Matthias

68

Sounds good.

69

One question though: what is the top-level container name?

package

Do you equate
one package with one container, or does the plural "packages" signify
something more collection-ish?

I see them as one to one. e.g. a person submits their “package” (singular container) to the community repo which will have many such “packages” in it that users will browse through and interact w/ on an individual basis.

- Jon

70

I see benefits in two separate repos:

1) pull requests easier to verify — there won’t be client bug fixes mixed in w/ package submission requests.

2) easier to avoid accidental recursive submodule updates that go out and "fetch the world" — the client can add package repositories “git clone” instead of as submodules located directly in client’s git repo.

3) cleaner way for client to interface w/ multiple package collections if there ever comes to exist ones not maintained by the Bro project.

So repos can be:

  client: bro-pkg
  community packages: bro-pkg-community

bro-pkg then would have a default URL that points to bro-pkg-community as it’s hosted on bro.org. It could also point to the bro-pkg-community github mirror, but I don’t see a reason for that. Just mentioning in case someone does.

- Jon

71

> Do you equate one package with one container, or does the plural
> "packages" signify something more collection-ish?

I see them as one to one.

Okay, that's what I was thinking as well.

    Matthias

72

I see benefits in two separate repos:

Yep.

  client: bro-pkg
  community packages: bro-pkg-community

I'm not sure if I understand the -community suffix. The client bro-pkg
makes sense to me. But the first association I have with
bro-pkg-community is a community-version of bro-pkg (i.e., the client).
How about just "packages?" Forking github.com/bro/packages feels like a
natural and understandable descriptor.

    Matthias

73

And to throw another idea in that is in line with this - what about calling the community package repository "packages" like matthias said and the client repository "package-manager"?

github.com/bro/package-manager also seems quite clear :slight_smile:

Johanna

74

I'm not sure if I understand the -community suffix. The client bro-pkg
makes sense to me. But the first association I have with
bro-pkg-community is a community-version of bro-pkg (i.e., the client).

Was mostly thinking it’s nice to indicate some way in the name that the contents of the repo aren’t authored by the bro team. Doesn’t have to be a suffix, could be “bro-community-packages” or “community-packages”.

How about just "packages?" Forking github.com/bro/packages feels like a
natural and understandable descriptor.

To me, a URL like that has a subtle implication that the packages are authored by the “bro” account, but that could be easy to clarify in the repo description: “These are packages contributed by the community”.

I like the “packages” + “package-manager” combo that Johanna suggests.

- Jon

75

I like the “packages” + “package-manager” combo that Johanna suggests.

+1

    Matthias

76

I like that too. It feels nice and clean.

  .Seth

77

I like the positioning of this because suddenly it suddenly feels very natural to explain the contents of a package (or whatever it ends up getting called).

  .Seth

78

Just a heads up. It seems bpkg is no longer a unique name.
http://www.bpkg.io

-AK