[pacman-dev] [RFC] Find real library names with libdepends/libprovides

[Mohammad_Alsaleh]

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.