search

rpm-software-management / librepo

A library providing C and Python (libcURL like) API for downloading packages and linux repository metadata in rpm-md format
http://rpm-software-management.github.io/librepo/
GNU Lesser General Public License v2.1
74 stars 91 forks source link

Add API/support for waiting on network #259

Closed cgwalters closed 1 year ago

cgwalters commented 2 years ago

Breaking this out from https://github.com/coreos/rpm-ostree/issues/3096

Basically I'm thinking we could add something like 

lr_handle_setopt(priv->repo_handle, error, LRO_NETWORK_WAIT, TRUE);

This would end up parsing the URL baseurl or metalink and using https://developer-old.gnome.org/gio/2.68/GNetworkMonitor.html to wait until the URL (host) was reachable.

A big question in my mind is - could we actually enable this by default? It's tempting to try, but the "blast radius" seems large too. So perhaps better to opt-in to start at least.

There's someone on the CoreOS team interested in working on this potentially; does this proposal make sense to you?

kontura commented 2 years ago

If I understand correctly this would wait for the clients network interfaces. So for example when a workstation is starting it is possible to run dnf before the network is fully setup and with this change it would wait instead of failing.

This would make sense for us, we even have a fix for such a problem with dnf-automatic: https://github.com/rpm-software-management/dnf/pull/1616

I also think that it shouldn't be such a problem if it was ON by default. For dnf perhaps we could make it a default in dnf5 and keep it as opt-in in dnf4.

cgwalters commented 2 years ago

If I understand correctly this would wait for the clients network interfaces. So for example when a workstation is starting it is possible to run dnf before the network is fully setup and with this change it would wait instead of failing.

Right.

This would make sense for us, we even have a fix for such a problem with dnf-automatic: https://github.com/rpm-software-management/dnf/pull/1616

Yeah, using GNetworkMonitor is better than a polling approach - it will avoid wasting CPU/energy.