This is completely correct, as no package provides libicui18n.so (of any version).

The wiki page merely states that if such a dependency exists, makepkg will attempt to add the version component. You can ignore installing the dependencies using makepkg --nodeps, and makepkg will successfully build the package with a dependency on libicui18n.so=63-64 (assuming one of the files in the resulting package is linked to the shared library libicui18n.so.63), which will then fail to install as no package provides that dependency.

Thanks for the explanation. My complaint would then be that the documentation I referred to is not clear on this point. Where is the appropriate place to raise that? There is no distinction between the usage of keywords like 'depends' vs their non-keyword usage.

PS - this whole thing where it's impossible to reasonably discuss a submission before it's closed/locked doesn't work very well.

I was going to say, if you feel the wiki is not clear enough, you should open a discussion on the wiki talk page. But the wiki just repeats what the PKGBUILD(5) manpage says...

That being said, I'm not sure how this is unclear. The depends array is a list of keywords corresponding to packages or package "provides" which the package requires, and the docs state that the depends "*.so" will be checked to "try to find a binary that depends on the library in the built package and append the version needed by the binary" -- is this wording unclear that the only thing which is happening is a modification of the keyword in question?

Did we accidentally imply somewhere, that all packages automatically generate *.so "provides" keywords? Because the docs for the "provides" array state you can do the same thing with *.so there as well.

Here's the 'depends' text from the wiki:
-----------
depends
An array of packages that must be installed for the software to build and run. Dependencies defined inside the package() function are only required to run the software.

Version restrictions can be specified with comparison operators, e.g. depends=('foobar>=1.8.0'); if multiple restrictions are needed, the dependency can be repeated for each, e.g. depends=('foobar>=1.8.0' 'foobar<2.0.0').

Dependencies that are provided by other dependencies do not need to be listed. For instance, if a package foo depends on both bar and baz, and the bar package depends in turn on baz too, baz does not need to be included in foo's depends array.

If the dependency name appears to be a library, e.g. depends=('libfoobar.so'), makepkg will try to find a binary that depends on the library in the built package and append the version needed by the binary. Appending the version yourself disables automatic detection, e.g. depends=('libfoobar.so=2').
-----------

This defines the contents of the 'depends' array very specifically as 'packages' and requires you to assume 'package names' is the intended content. The definition is then modified with details about constraining via version numbers. The last item then explains a special use case where a string that looks like a library file name can cause special handling that causes the built package to depend on that string and the version of the library that string causes the detection of via binaries in the package being linked to.

That last line is poorly explaining 'magic' since 'depends' was strictly defined as containing 'packages' leading to the implied 'package names' interpretation. There are *no* packages with .so in the name so yes there is further magic implied at the other end of this equation. Nowhere here is any interaction with 'provides' mentioned which might have directed me to read what the other end of that equation actually is.

Here's 'provides' the text from the wiki:
-----------
provides
An array of additional packages that the software provides the features of (or a virtual package such as cron or sh). Packages providing the same item can be installed side-by-side, unless at least one of them uses a conflicts array.
-----------

Again, a definition that states 'packages' implying package names as being the contents of the array. Then we explain 'virtual packages' in a way that clearly shows we are talking about 'capabilities' eg: 'cron' is the capability name for a number of command scheduling tools commonly referred to as cron replacements.

Here there is nothing attaching 'provides' to 'depends' as opposite ends of an equation that needs to balance. There is only the special case of virtual packages / capabilities. By act of omission and not explaining the ties between 'provides' and 'depends', the 'magic' implied by the 'depends' definition is not dispelled or explained further.

For all I knew, buried in the operations of pacman was maintenance of a list of libraries and their versions in order to make the 'depends' thing work, just like a list of packages is maintained without the requirement of 'provides' being defined. It may not be implied, but it certainly isn't denied.


To directly address your comment, you said it yourself: 'The depends array is a list of keywords corresponding to packages or package "provides" which the package requires' but that specificity is not actually in the wiki or man page. So moving forward, I think that the various keywords that are opposite ends of equations that pacman attempts to balance should have that relationship within their definitions. Also the 'provides' explanation should include the other half of the depends library case to forego any implication and to fully cover both sides of the special use cases that are present.


Thanks for your time and willingness to hear me out.