[pacman-dev] [RFC] Find real library names with libdepends/libprovides
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. 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
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.
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
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
On 09/05/13 14:52, Mohammad_Alsaleh wrote:
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.
Ah. So libpng is interesting... it has: libpng.so -> libpng16.so -> libpng16.so.16.2.0 Putting libpng.so in provides does not work. But putting libpng16.so does. And the actual library software links to is libpng16.so meaning that should be in the depends line too. I refuse to have makepkg actually change the specified dependency. It is only allowed to add a version to it. So this is not a bug. Allan
On Thu, May 09, 2013 at 04:38:36PM +1000, Allan McRae wrote:
On 09/05/13 14:52, Mohammad_Alsaleh wrote:
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.
Ah. So libpng is interesting... it has: libpng.so -> libpng16.so -> libpng16.so.16.2.0
Actually, the more interesting examples are the ones where you have lib$name -> lib$name-$version.so.$so_major.$so_minor but lib$name-$version.so does not exist. Take libevent as an example: libevent.so -> libevent-2.0.so.5.1.9 libevent-2.0.so.5 exists. But libevent-2.0.so does not. Adding libevent-2.0.so to provides/depends works. But that might not be obvious. And those non-standard cases add a burden to package maintainers if this feature is ever going to be widely used.
Putting libpng.so in provides does not work. But putting libpng16.so does. And the actual library software links to is libpng16.so meaning that should be in the depends line too.
I refuse to have makepkg actually change the specified dependency. It is only allowed to add a version to it. So this is not a bug.
FWIW, my patches might add a proper lib{provide/depend} based on the specified dependency. But they wouldn't change it. I understand that my solution is possibly over-engineered. That's why I suggested the alternative approach of promoting unversioned libprovides from a warning to an error to avoid them going unnoticed.
participants (4)
-
Allan McRae
-
Dave Reisner
-
Mohammad Alsaleh
-
Mohammad_Alsaleh