[Bro-Dev] Package manager meta data

Jan Grashöfer jan.grashoefer at gmail.com
Fri Oct 28 15:52:58 PDT 2016


> That could be misleading.  The purpose of putting those tags in bro-pkg.index is because they are related to package “discoverability” and it’s easier to search that data if it’s located in a single repo, the package source, rather than having to download the entire universe of packages up front.
> 
> If bro-pkg.meta is allowed to “override” those fields just for the purpose of displaying metadata in the “info” command, it’s misleading because that is not the actual data that’s searchable via the “search” command.

I totally agree that overriding information can be misleading but it
might be worth compared to the other options.

> If it’s important to always have some sort of “description” field to display from the “info” command, which would help situations where a package was never located via a package source (e.g. installed directly by git URL), then I’d suggest maybe either displaying contents of the README or just having a differently-named field.  Since the user has already found the package, maybe it’s more useful for them to have a “usage” or “quickstart” field that gives them some high-level view of the API or options to tweak.

For me, introducing another field in bro-pkt.meta just increases
confusion. Displaying the README seems to be the easiest solution but I
think the behavior is still a bit confusing. Correct me if I am wrong
but bro-pkg.meta contains stuff like script_dir and dependencies (so
rather technically), whereas bro-pkg.index contains the descriptive
information like info text and tags (which is metadata, too, one could
even argue it's "more meta" than script_dir etc.).

>From the user/developer perspective and excluding the technical
realization, I think the most desirable solution would be to have a
single file to put the meta data in, so that a package is completely
self-describing. This would also allow to provide different descriptions
for different versions.

Regarding the technical solution, I'll try to sum up: Using a
distributed structure implies that important information is distributed,
too. I think the first question is, where to aggregate the information?
One could either maintain a cache in every client or integrate it into
the list of packages aka the public repository (current implementation).
The second question would be, whether and how to synchronize the
information? If the info is part of the repository this can be either
done manually (more or less the overriding solution of the current
implementation, assuming that the developers keep meta data in sync) or
automatically (e.g., by a script that fetches meta data of packages once
a day). If the cache is part of the client, this could be done based on
an expiration threshold or intentionally by the user (similar to dnf).
Finally one could drop the requirement of synced package and repository
meta data, risking to confuse the users. In that case the information
contained in the package should be used whenever possible (e.g., the
info command for a not installed package could obtain the most recent
information from the package's git repo).

The current implementation avoids synchronization by splitting the
information at the cost of non-self-describing packages. In general I
would vote for completely self-describing packages (might also make
bundling easier). The different aggregation and synchronization options
have their own pros and cons.

Another question: Now that repositories only contain bro-pkg.index files
with links instead of submodules, how are deleted/unavailable packages
detected/removed?

Best regards,
Jan


More information about the bro-dev mailing list