Metadata in a custom subdirectory outside of `repodata`

[jkroepke]

I tried to setup an YUM repository with GitHub packages, but while repository URLs are valid, it fails somehow.

# cat /etc/yum.repos.d/openvpn-auth-oauth2.repo 
[myrepo]
name=openvpn-auth-oauth2
baseurl=https://github.com/jkroepke/openvpn-auth-oauth2/releases/download/
enabled=1
gpgcheck=0

RockyLinux:

dnf --setopt=debuglevel=10 repolist
timer: config: 1 ms
DNF version: 4.14.0
Command: dnf --setopt=debuglevel=10 repolist 
Installroot: /
Releasever: 9
cachedir: /var/cache/dnf
Base command: repolist
Extra commands: ['--setopt=debuglevel=10', 'repolist']
python3.9: /builddir/build/BUILD/librepo-1.14.5/librepo/yum.c:1365: lr_yum_download_remote: Assertion `(ret && !tmp_err) || (!ret && tmp_err)' failed.=============] 4.2 kB/s | 1.5 kB     00:00 ETA
Aborted

Fedora

dnf --setopt=debuglevel=10 update
Updating and loading repositories:
 Fedora 42 openh264 (From Cisco) - aarch64                                                                                                                   100% |   5.3 KiB/s |   6.0 KiB |  00m01s
 Fedora 42 - aarch64 - Updates                                                                                                                               100% |   1.7 MiB/s |   6.0 MiB |  00m04s
 openvpn-auth-oauth2                                                                                                                    100% [==================] |   1.1 KiB/s |   1.5 KiB |  00m00s
(process:23): GLib-CRITICAL **: 13:35:16.612: g_str_has_prefix: assertion 'str != NULL' failed
dnf: /builddir/build/BUILD/librepo-1.19.0-build/librepo-1.19.0/librepo/yum.c:1365: lr_yum_download_remote: Assertion `(ret && !tmp_err) || (!ret && tmp_err)' failed.
Aborted

[kontura]

The abortion really should be fixed and librepo should report the error properly. I have created a PR that should do that: #341

The actual error is: Invalid path: v1.23.0/d0fb7563ed2b3e1f08face2e565b188b92b6c26a906dee9ec0726056a52cc30e-primary.xml.zst
This is a path from repomd.xml and it doesn't seem to be available so the repository probably needs some fixing as well.

[jkroepke]

@kontura I checked the path and

baseurl: https://github.com/jkroepke/openvpn-auth-oauth2/releases/download/
path: v1.23.0/d0fb7563ed2b3e1f08face2e565b188b92b6c26a906dee9ec0726056a52cc30e-primary.xml.zst

exists:

https://github.com/jkroepke/openvpn-auth-oauth2/releases/download/v1.23.0/d0fb7563ed2b3e1f08face2e565b188b92b6c26a906dee9ec0726056a52cc30e-primary.xml.zst

[kontura]

I see, you are correct.

It looks like librepo is not able to deal with the fact that the primary is in its own sub-directory v1.23.0.
I am kind of surprised we haven't seen this before but I guess basically all repositories have the files in repodata together with repomd.xml.

To clarify I believe the problematic repo looks like:

repodata/
├─ repomd.xml
v1.23.0/
├─ primary.xml
├─ filelists.xml
├─ other.xml

[jkroepke]

I am kind of surprised we haven't seen this before but I guess basically all repositories have the files in repodata together with repomd.xml.

I guess most repositories are using createrepo, to setup a YUM repo, which is valid and the standard behavior.

But in my case, I maintainer of https://github.com/jkroepke/openvpn-auth-oauth2 and I tried to mimic a YUM repository, using GitHub releases.

It works very well for APT repositories, since APT repositories don’t require any specific directory structure.

To clarify I believe the problematic repo looks like:

Yes, correct. Technically, GitHub Releases does not support subdirectories, but repodata/repomd.xml is a hard requirement for YUM repositories. To fulfill this, I created a release named repodata, and the repomd.xml file points to the files present in the v1.23.0 release. This explains the different folder structure. The subfolders represent different releases on GitHub.

As I understand it, putting all metadata files into the repodata release would at least mitigate the issue.

[kontura]

As I understand it, putting all metadata files into the repodata release would at least mitigate the issue.

Yes, I believe that should work.