I don't agree. The edge cases would just cause needless headaches.

Example: msmtp provides the facility 'smtp-forwarder', but has no conflicts.

from ssmtp PKGBUILD :
conflicts=('exim')
provides=('smtp-forwarder')

from exim PKGBUILD :
provides=('smtp-server')
conflicts=('smtp-server')

That suggests an inconsistency.

It also looks as though we should distinguish between 2 types of provides :

- providing something virtual like smpt-forwarder
- providing an existing package like mesa

To me it seems in both situations we have a provides/conflicts/replaces combo.

I'm sure I can come up with examples where each of provides/replaces/conflicts can be used on their own.

Please do, Allan, Falconindy (and others).

I have a strong feeling that we'll find that those examples use provides/conflicts/replaces wrong.

example :
ati-dri has
depends=("libgl=${pkgver}")
pkgdesc="Mesa DRI + Gallium3D r300 drivers for AMD/ATI Radeon"
conflicts=('xf86-video-ati<6.9.0-6')

conflicts is used wrong imo here, it should be like this :
depends=("libgl=${pkgver}" 'xf86-video-ati>=6.90-6))
pkgdesc="Mesa DRI + Gallium3D r300 drivers for AMD/ATI Radeon"
conflicts=()

if people try to install ati-dri before xf86-video-ati this might lead to a circular dependency.
xf86-video-ati depends on ati-dri & ati-dri depends on xf-86-video-ati
Does this cause problems for pacman dependency handling ?

Examples of using only one of provides/conflicts/replaces:

python2 conflicts with python<3
msmtp provides smtp-server
libreoffice replaces openoffice-base

They do serve a purpose separately...

Ok, then there are cases where replaces and conflicts are used independently .

Changing the suggestion as follows :

new meaning of provides , no other changes :

provides also implies conflicts and replaces

example :
foo_new provides foo
this should be interpreted as :

foo_new provides foo
foo_new conflicts with foo
foo_new replaces foo

So... ignoring the provides only case above?

syslog-ng provides the 'logger' facility, but has no conflicts (there are other loggers).
xorg-server provides x-server but has no conflicts (there are other implementations of X).
bash provides sh, but doesn't conflict...

I can keep looking through the repos...

This is silly. We've come up with cases where the simple logic doesn't work, and we haven't even gotten to proposing a sane transition plan as well as the necessary code changes. It's not worth changing the semantics of something that has stood for literally years to save one line of code in a PKGBUILD, and lose flexibility while doing so.

I created this feature request as i thought it was the best way to let developers know my thoughts and start a discussion about this change.
It seems i did not make clear the logic behind the new provides meaning, i'll attempt to clarify.

package fooA provides foo
package fooB provides foo

does pacman allow to have both fooA and fooB installed ?
If the answer is yes, then my suggestion for a new meaning of provides doesn't make sense and this feature request can be closed.
However if the answer is no, then 'provides foo' implies a conflict between fooA and fooB.
this implied conflict is not mentioned at all in the manpages.

example :
metalog and syslog-ng both provide logger.
neither of those packages has a conflicts or replaces array in the pkgbuild.
Does pacman allow both metalog and syslog-ng to be installed ?


about transition plan / code changes :
if pacman / makepkg developers are not convinced this is a good change, there's no point in doing those.

> does pacman allow to have both fooA and fooB installed ?
Yes.

> Does pacman allow both metalog and syslog-ng to be installed ?
yes.

There are plenty of cases where provides can be used on its own. So...
> then my suggestion for a new meaning of provides doesn't make sense and this feature request can be closed.