### Summary We use the gitlab package registry with conan v1.44 and have not changed our host system in several years. Early the week of August 4th, the host system went from functional to non functional in its ability to download conan v1 packages hosted on the gitlab registry. The `conan search` command shows the packages on the gitlab registry, however, `conan install` fails with `package_name/version@someuser/somechannel was not found in remote 'gitlab'`. Upon further investigation, we were able to determine that having package revisions enabled in our conan.conf was causing a 404 to be generated that had never previously been generated. When we disable package revisions in conan.conf, we are able to download from the gitlab package registry properly. ### Steps to reproduce 1. Install python version 3.8.12 2. Install conan version 1.44.0 3. Set `revisions_enabled = 1` in your conan.conf 4. Add your gitlab remote (`conan remote add gitlab <remote_url>`) 5. Authenticate your user (`conan user -r gitlab -p`) 6. Upload a dummy package (`conan upload <package_name>/<version>@<user>/<channel> --all -r gitlab`) 8. Install that package (`conan install <package_name>/<version>@<user>/<channel> -r gitlab`) This should give you the not found error as described above. 1. Remove `revisions_enabled` from your conan.conf 2. Install the package (`conan install <package_name>/<version>@<user>/<channel> -r gitlab`) This should now allow you to download the url <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> ### What is the current *bug* behavior? The *bug* is that previously we had revisions_enabled for conan v1 and now on all of our host systems we are unable to install conan v1 packages without updating all of our conan.conf files. I'm not quite sure if this is a misconfiguration on our end because I believe package_revisions work for other remotes and have historically never quite worked for gitlab. I'm not sure why we randomly started getting 404s, but I presume the REST API on gitlab was updated and is now incompatible with conan v1. I looked at the source for conan 1.44.0 and verified that based on the remote capabilities, the url router in conans rest api client could produce two different routes (a rest api v1 route and a rest api v2 route). The reason I believe this could be a bug is the remote capabilities that gitlab is advertising might've been updated while not being backwards compatible with older versions of conan (<= conan 1.44.0). Therefore, our conan v1 client is generating a v2 rest api route, but that route is not properly supported by the server side rest api that gitlab has implemented. Please correct me if I'm wrong. ### What is the expected *correct* behavior? `conan install <package_name>/<version>@<user>/<channel> -r gitlab` works again without updating the conan.conf on every one of our conan client hosts. ### Relevant logs and/or screenshots CONAN_LOGGING_LEVEL=10 output with revisions_enabled=1 ``` DEBUG :rest_client.py [58]: REST: Cached capabilities for the remote: ['revisions'] [2025-08-07 10:36:27 ,322] DEBUG :rest_client.py [188]: REST: get: https://gitlab.com/api/v4/projects/<PROJECT ID>/packages/conan/v2/conans/<package_name>/<version>/_/_/latest [2025-08-07 10:36:27,323] DEBUG :rest_client_common.py[30]: REST ERROR: <class 'conans.errors.NotFoundException'> [2025-08-07 10:36:27,323] ``` CONAN_LOGGING_LEVEL=10 output with revisions_enabled commented out ``` DEBUG :rest_client.py [58]: REST: Cached capabilities for the remote: ['revisions'] [2025-08-07 11:11:17,780] DEBUG :rest_client.py [188]: REST: get: https://gitlab.com/api/v4/projects/<PROJECT ID>/packages/conan/v1/conans/<package_name>/<package_version>/<user>/<channel>/download_urls [2025-08-07 11:11:18,781] DEBUG :rest_client.py [130]: DOWNLOAD: https://gitlab.com/api/v4/projects/<PROJECT ID>/packages/conan/v1/files/<package_name>/<package_version>/<user>/<channel>/0/export/conanmanifest.txt [2025-08-07 11:11:18,310] ``` <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->