While, hypothetically, you could rewrite the createrepo task to avoid using direct file access to /mnt/koji, the current version is highly dependent on it.

The task defines self.pathinfo = koji.PathInfo(self.options.topdir) and uses it extensively.

At present we rely on createrepo accessing the fs directly to gather rpm metadata from the rpms listed in the pkglist. If we can't get createrepo to do that for us, then we'd have to provide the rpm metadata to it some other way, which would likely be tantamount to re-implementing a significant portion of createrepo logic ourselves.

The --update-md-path only works with --update and only tells createrepo where the original repo to pull from is. We still need something to create that original repo, and to fetch the metadata for rpms that have been updated.

I don't really see options in createrepo_c that would enable this (e.g. a feature where createrepo_c would read rpm files from https rather than local). Even if that existed, sounds potentially very fragile?

I've already closed this. New files are really the problem here. I was thinking that crearetepo_c also already supports remote rpms (via pkglist) but that's not true. a) update createrepo_c to support remote rpms b) use some (fuse?) layer to reach to proxy files from pkglist. I don't think it is worth the work now. Idea was to support cloud createrepo builders as there are troubles with NFS mounts.