I'm going to reply here before going into details about the individual patches if that's okay. On Wed, May 08, 2013 at 07:59:53PM -0400, Dave Reisner wrote:
On Thu, May 09, 2013 at 12:15:27AM +0300, Mohammad Alsaleh wrote:
makepkg only handles libprovides/libdepends correctly if the naming scheme is:
lib${name}.so --> lib$name.so.$ver
But it is not uncommon for libname.so to link to a '.so' file that does not follow this naming scheme. For example, these 2 schemes are sometimes used: lib$name.so --> libname$major.$major.$minor lib$name.so --> libname-$major.$major.$minor
There exists other schemes.
Can you point out where these exist in the wild? They're hugely non-conformant, and glibc's ldconfig won't even read these files without specific nudging. I'm not sure how other implementations behave.
Attaching a small script that should list all cases in '/usr/lib'. There are 72 library names detected by this script in my system. Actually, I came across this when I wanted to suggest adding libprovides to popular libraries after libpng's upgrade. And when I tested adding 'libpng.so' to provides. I discovered that current code in makepkg wouldn't work. Investigating this further, I discovered that libpng is not a corner case as shown by the output of the small script attached.
With those cases, and before these patches, makepkg would add lib$name.so to provides unversioned and display a warning.
And if another package adds lib$name.so as a dependency, the build will succeed and only a warning will be displayed.
Not only makepkg fails to find version/arch for libraries in those scenarios. But the success of builds in both provide/depend sides might give the illusion that versioned sodepends are actually honored.
If the idea behind these 2 patches is rejected. I would like to propose promoting the warning in find_libprovides() to an error.
[PATCH 1/2] makepkg: Search/Add real library names libprovide link to [PATCH 2/2] makepkg: Search/Add real library names libdepend link to