systemd-resolvconf provides a limited implementation of resolvconf that only functions with systemd-resolv
https://github.com/systemd/systemd/commit/088c136384edb1d121ed40a6d3ecf4b7abade169

then resolvconf can be replaced by systemd-resolvconf?

What do you mean by "replaced"? If you're talking about the replaces array in the PKGBUILD then no that is not what this is about. systemd-resolvconf can never fully replace openresolv since it only supports systemd-resolved.

The intention of this feature request and  FS#59187  is for "systemd-resolvconf" and "openresolv" packages to provide and conflict with "resolvconf" instead of each other. Then other packages that need to use /usr/bin/resolvconf could depend on the virtual package "resolvconf".

my idea is use netctl with systemd-resolvconf

└───╼ sudo LC_ALL=C pacman -S systemd-resolvconf
resolving dependencies...
looking for conflicting packages...
:: systemd-resolvconf and openresolv are in conflict. Remove openresolv? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: removing openresolv breaks dependency 'resolvconf' required by netctl

but if you say is not compatible, then NVM

greetings

Ah, that's what you meant with "replaced".
It will be possible to use netctl with systemd-resolvconf when this bug (and also  FS#59459 ) gets fixed.

About compatibility, if you don't use systemd-resolved then systemd-resolvconf is useless. Read https://jlk.fjfi.cvut.cz/arch/manpages/man/resolvectl.1#COMPATIBILITY_WITH_RESOLVCONF(8) .

So it sounds like this can't really be implemented, as it doesn't really provide resolvconf if it only works in a very specific scenario.

Currently "systemd-resolvconf" provides and conflicts with "openresolv", it definitely doesn't provide all of openresolv's functionality. I don't see how changing it to "resolvconf" would be a problem.

@nl6720 if the resolver in use is the default glibc do you still consider systemd-resolvconf provides resolvconf just that it will not actually update resolvconf?

Ok, I get your point. Providing a /usr/bin/resolvconf that does not work is not a good idea, so making packages depend on potentially non-working "resolvconf" is also bad.
I still think that the way "systemd-resolvconf" and "openresolv" conflict should be changed.

How about:

systemd-resolvconf:
provides=('openresolv' 'resolvconf')
conflicts=('resolvconf')

openresolv:
provides=('resolvconf')
conflicts=('resolvconf')

Some facts about packages currently in the Arch repos: (as of 2018-10-06 20:36:58 EDT)

1. Packages that depends=('resolvconf'): 1: netctl
2. Packages that depends=('openresolv'): 0: (none)

3. Packages that optdepends=('resolvconf'): 0: (none)
4. Packages that optdepends=('openresolv'): 3: wireguard-tools, dhcpcd, vpnc

5. Packages that satisfy a 'resolvconf' dependency: 2: openresolv, systemd-resolvconf
6. Packages that satisfy an 'openresolv' dependency: 2: openresolv, systemd-resolvconf

Some facts about packages currently in the AUR: (as of 2018-10-07 ~03:51 EDT)

1. Packages that depends=('resolvconf'): 1: mullvad-old
2. Packages that depends=('openresolv'): 6: avpnc, networkmanager-git, openvpn-update-resolv-conf-git, protonvpn-cli, vpn-unlimited, vpnfailsafe-git

3. Packages that optdepends=('resolvconf'): 0: (none)
4. Packages that optdepends=('openresolv'): 12: dhcpcd-git, dhcpcd-without-systemd, libnm-git, libnm-glib-git, networkmanager-consolekit, networkmanager-consolekit-noscan, networkmanager-git, networkmanager-ifupdown, networkmanager-noscan, vpnc-fortigate, vpnc-juniper-git, wireguard-tools-git

5. Packages that satisfy a 'resolvconf' dependency: 4: systemd-resolvconf-selinux, systemd-resolvconf-git, openresolv, systemd-resolvconf
6. Packages that satisfy an 'openresolv' dependency: 5: openresolv-openrc, openresolv-git, systemd-resolvconf-selinux, systemd-resolvconf-git, systemd-resolvconf

Note that because `netctl` is in groups=('base'), and its dependency on 'resolvconf' is satisfied by both systemd-resolvconf and openresolv: Running `pacstrap /mnt base` prompts whether to install systemd-resolvconf or openresolv. It is usually not the case that installing 'base' has ambiguities like that.

pacstrap doesn't prompt by without the -i option, AFAIK it chooses the package alphabetically.

This issue is no longer about getting packages to depend on resolvconf, but about making this happen:

systemd-resolvconf:
provides=('openresolv' 'resolvconf')
conflicts=('resolvconf')

openresolv:
provides=('resolvconf')
conflicts=('resolvconf')

It displays the prompt, but it automatically chooses one (alphabetically) without -i.

Currently, the package has had resolvconf added to its provides field d̶u̶e̶ ̶t̶o̶ ̶t̶h̶i̶s̶ ̶f̶e̶a̶t̶u̶r̶e̶ ̶r̶e̶q̶u̶e̶s̶t̶*. Is this really desirable? If so, then why does it provide it, but conflict on the specificity of openresolv, rather than anything which may (theoretically come along and) provide resolvconf?

(We can solve the netctl ambiguity by removing netctl from the base group where it doesn't belong.)

* or rather released after, but committed to trunk before...

> Currently, the package has had resolvconf added to its provides field due to this feature request.

Git says that eworm did that 3 days before this feature request was opened.

Some of the above discussion is no longer relevant due to netctl no longer being in "base". But the original request still seems valid.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.