Arch Linux User Repository

There can be some legitimate niche scenarios when a suffixed package should not have the provides field. But those are very rare I believe.

Such a case would be if e.g. subconverter-bin is not drop-in compatible with subconverter. E.g. if installing subconverter-bin would destroy the existing user config created by subconverter.

But even that scenario is more a counter-example, because in such a situation, it would be much better for subconverter-bin to make a backup copy of an existing user config upon installation, and warn the user about the possibility of data corruption / loss which might necessitate manual data restoration.

TLDR; if subconverter-bin does not have provides=subconverter, it logically implies that for some reason, subconverter-bin is not drop-in compatible with subconverter.

And if subconverter-bin is denied having a provides=subconverter entry, the alternative is that you would have to monitor the AUR constantly to catch if there is any new subconverter package, e.g. subconverter-git, subconverter-appimage-bin, subconverter-snapshot-bin, etc. etc., and add all those names to the conflicts field of subconverter-bin.

There is a very good and logical reason why the IT engineers who designed the Arch packgaging system decided to have both a provides and a conflicts field. It is not a superfluous duplication, and it is not because they just like to uselessly declare the same thing twice.

The provides is also necessary because there is no centrally and automatically enforced gatekeeping that ensures that at all times there is no possible problems between alternatively named packages for the same application.

Let's say there is only AUR/subconverter and AUR/subconverter-bin. If the latter only declares its conflicts but not provides, there's not yet any clash.

But let's say someone creates a subconverter-beta-bin, which also only conflicts with 'subconverter'. In that case, a user who has subconverter-bin cannot successfully install subconverter-beta-bin in one step, because 1) pacman will try to install subconverter-beta-bin without uninstalling subconverter-bin, and 2) during file copying, pacman will fail that transaction due to filesystem level conflicts, and abort the whole operation.

Only if every package declares its common "essential" name in provides & conflicts fields can it be guaranteed that a user can successfully complete any such transaction.

Please bear in mind that the package with the name 'subconverter' already provides 'subconverter' and conflicts with 'subconverter'. That is, every package has an implied provides & conflicts entry, both of which equals its pkgname.

The necessity of the provides field does not depend on if there are downstream consumer packages or not. It is mandatory for "non-default-source" packages like -bin, -git etc.

Also if I use an AUR helper to install 'subconverter', I want it to ask which alternative I want. If this package does not have that name in the provides field, the AUR helper won't ask me if I want 'subconverter' or 'subconverter-bin'.

Please don't invent your own rules. Please follow the established AUR standards.

The updated version can't load bundled rules.

This make using default rule sets offline with the simpler generating option more difficult.

It seems that the packaging location should be revised.