How to gracefully deprecate remote repo?

[gershnik]

Consider the following scenario. There is a custom remote repository accessed via HTTP that multiple clients are pulling packages from. For one reason or another this repository needs to be removed and replaced by a completely different one with different location and signing keys.

Is there a way to notify clients about it, as they perform dnf upgrade, either via some HTTP level response or repository XML metadata?

Something like a warning message or an error saying "Hey the repository foo is going away please move to repository bar. More details at http://yadayada.com/migration".

As far as I can see from google searches and reading dnf, libdnf and librepo code there isn't a way to do that but perhaps I am not looking properly.

It's a pity if the only way to handle this situation is to turn off the original repo HTTP server and rely on clients to figure out how to deal with the error via some side channel.

Thank you!

[m-blaha]

Distributions usually set repositories using a specific package. For example Fedora has the fedora-repos package which owns repo files in the /etc/yum.repos.d/ directory. This way it's possible to make changes in repositories using regular package update. Regarding a messaging - maybe you can use motd, but that would require adding a file into the /etc/motd.d directory which is quite similar to creating a repo file directly.

[gershnik]

Well yeah, if the repository is installed via some updatable mechanism then there is no issue to begin with. My question is specifically about repositories whose definitions cannot be automatically updated by something else. A custom in-house repo for example.

Thank you!

[ppisar]

I'm not aware about any mechanism you want on the repository level. Repository can have an updateinfo file https://github.com/openSUSE/libzypp/blob/master/zypp/parser/yum/schema/updateinfo.rng which can deliver messages to the users, but they are always tied an installed package.

I think the easiest way is solve it on HTTP level. Configure the server to return an error and place the instructions in the response body. DNF won't show it, but users accessing the location from a web browser will see it. Or if you can nourish the old location indefinitely, place an HTTP redirect there.

[gershnik]

So basically, as I was afraid from the beginning, there is no way to gracefully produce error/warning on either HTTP or repository level. I realize that this is a niche problem currently as most people get software from root distribution repos that aren't likely to need to be replaced. Still it is a problem for some and it contributes to "it's hard to deploy custom/in house software to Linux" sentiment. Fundamentally, any software that fetches something remotely should have a facility for remote end to produce a warning/error that is surfaced to the end user. So please consider this a feature request 🙂

[ppisar]

I will move this request to librepo project as it the piece of code which downloads repository metadata.

[ppisar]

Delivering a new location or the end-of-life notice on HTTP layer (Status 301, 500) would have a problem with mirrors and that a repository locator can contain DNF variables ($basearch, $releasever).

Therefore I'd rather augment repomd.xml. That will also enable reusing existing signature mechanism. Instead of new URL we could maybe ship a new *.repo file as an attachment to the repository. That would enable changing not only the repository URL, but also PGP location, caching policy, repo ID etc.