> 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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
