I happened to check a package that stood out to me after an `eix-sync` (net-misc/danbooru-grabber, from the 'octopus' overlay) and noticed it lacked a metadata.xml file. Upon further inspection with `find -name metadata.xml` inside the 'octopus' overlay, it returned only 3 results. Additionally, there are still CVS '$Id$' lines, despite the overlay being maintained in Git. This overlay needs cleaning up, starting with filling the missing metadata files. The maintainer(s) of the overlay can find more details at [1] and the formal spec for metadata.xml at [2]. Running `repoman scan` is also suggested, at minimum, to catch other issues. Reporting here since upstream [3] does not seem to have a public-facing means of contacting them, such as e-mail. [1]: https://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/index.html [2]: https://wiki.gentoo.org/wiki/GLEP:68 [3]: https://github.com/Bfgeshka
Actually there were some ways of contacting me. For example, you could create an issue, or, since you were inspecting metadata, you were able to look for email in repositories.xml. I've never knew that metadata.xml files are really mandatory to be because very often I've seen overlays without then. Anyway, since you look like a big deal I guess I'll have to supply ebuilds with metadata files or drop some of them completely since there are plenty of them.
(In reply to bfg from comment #1) > Actually there were some ways of contacting me. For example, you could > create an issue, or, since you were inspecting metadata, you were able to > look for email in repositories.xml. Ah, I didn't look in repositories.xml. My mistake. As for Issues, I do not have a GitHub account and do not agree to their Terms, so that option was automatically null for me. > > I've never knew that metadata.xml files are really mandatory to be because > very often I've seen overlays without then. They're not strictly mandatory for any tree except Gentoo's, but it makes it a lot easier for a user to figure out what's up with a certain package. For example, if someone builds a package of yours but it segfaults and the ebuild is fine, then instead of bugging you (the overlay maintainer), the user can reference metadata.xml to locate and talk to upstream. > > Anyway, since you look like a big deal I guess I'll have to supply ebuilds > with metadata files or drop some of them completely since there are plenty > of them. No need to drop the packages outright; if you need any help with establishing the metadata, I'm happy to offer guidance.
> For example, if someone builds a package of yours but it segfaults and the > ebuild is fine, then instead of bugging you (the overlay maintainer), the user > can reference metadata.xml to locate and talk to upstream. Understandable position, yet you're first person who had any need for that (and contacted me later) in my overlay. Usually I'm followng description link, served me well so far. > if you need any help with establishing the metadata, I'm happy to offer > guidance. Thanks for your awareness on this regard. To be perfectly honest, this work is not hard to do, but it is tedious and boring. And bureaucracy is not my thing. I've made metadata.xml only when is really was needed to be done (e.g. describing custom flags).
Metadata files are present for all packages. Fixing other minor things in progress and will be finished soon.
