pkgcheck-0.10.11 does not traverse directories in my overlay repo

[stefantalpalaru]

https://github.com/stefantalpalaru/gentoo-overlay

When I run pkgcheck scan, from the top-level dir of my overlay repo, it exits with no output and with a zero status code after a few seconds.

pkgcheck scan */*/*.ebuild shows plenty of output, so it somehow fails to traverse subdirectories.

[mgorny]

You list only one category in profiles/categories, so you shouldn't expect it to scan more than one category.

[stefantalpalaru]

You list only one category in profiles/categories

The rest should be inherited from the master repo.

so you shouldn't expect it to scan more than one category

It doesn't even scan that one category. So much for a Repoman replacement...

[thesamesam]

It's unclear to me that it should actually inherit from reading PMS?

[stefantalpalaru]

It's unclear to me that it should actually inherit from reading PMS?

"/etc/portage/categories is a file that contains a simple list of valid categories that may be used in repositories and the PKGDIR variable. The existence of a categories allows for custom package categories to be created. Custom overlays may define profiles/categories relative to their overlay root." - https://wiki.gentoo.org/wiki//etc/portage/categories

[mgorny]

How is some random wiki article about /etc/portage directory affect package manager behavior regarding profiles/categories file?

[ulm]

PMS says in section 4.4:

If the repository is not intended to be stand-alone, the contents of these files are to be taken from or merged with the master repository as necessary.

[arthurzam]

@stefantalpalaru Thanks for the report. Even though for such things we prefer to quote PMS, and the Wiki has less reliable precise info, in this case you are right, and it indeed needs to merge the categories from master overlays.

I'm reopening, and I think I know how it should be done, but sorry, it will take time (I'm busy for the near future, but will fix it)

[radhermit]

I think you guys are arguing about red herrings, but anyway at a glance it appears to be a bug in the repo path restrict generation, i.e. do something like this:

diff --git a/src/pkgcore/ebuild/repository.py b/src/pkgcore/ebuild/repository.py
index fd0f467c..904d99da 100644
--- a/src/pkgcore/ebuild/repository.py
+++ b/src/pkgcore/ebuild/repository.py
@@ -336,12 +336,13 @@ class UnconfiguredTree(prototype.tree):
         if path not in self:
             raise ValueError(f"{self.repo_id!r} repo doesn't contain: {path!r}")

+        path_chunks = []
         if not path.startswith(os.sep) and os.path.exists(pjoin(self.location, path)):
-            path_chunks = path.split(os.path.sep)
+            path_chunks.extend(path.split(os.path.sep))
         else:
             path = os.path.realpath(os.path.abspath(path))
-            relpath = path[len(os.path.realpath(self.location)):].strip('/')
-            path_chunks = relpath.split(os.path.sep)
+            if relpath := path[len(os.path.realpath(self.location)):].strip('/'):
+                path_chunks.extend(relpath.split(os.path.sep))

         if os.path.isfile(path):
             if not path.endswith('.ebuild'):

Alternatively, you could simplify/rework that path chunking logic if you like as well.