[pacman-dev] .so provides/depends patches review

[Xyne]

> Hi,
> 
> Sorry this has taken me a while...  so long in fact that I do not have 
> the original email stored anymore to reply to.
> 
> But here goes my comments on the patches for soname provides/depends:
> http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010431.html
> 
> My comments are currently only on functionality.  I'll get to code after 
> that is fully sorted.
> 
> Firstly, it works well and does as advertised.  So no issues there...  
> However:
> 
> 1) If I put a bad soname provides in the array (e.g. 
> provides="readline.so") it just silently ignores it.  No error and 
> nothing put in the .PKGINFO.  There needs to be an error (or at minimum 
> a warning).   The same goes for depends (although these are mostly 
> caught by the initial dependency checking in makepkg).
> 
> 2) Building readline on i686 with provides="libreadline.so", in the 
> .PKGINFO I get:
> provides = libreadline.so=6-elf32_i386
> My concern about that is that the library is not i386 but is i686.  I 
> may be prepared to accept that though as I guess x86 is x86 really...  
> But what additional information is the elf32 providing? I could perhaps 
> understand the operating system from the host triplet.   If anything, my 
> preferences are:
> libreadline.so=6-i686_linux (best)
> libreadline.so=6-i686 / libreadline.so=6-i386_linux
> libreadline.so=6-i386 (worst)
> 
> Allan
> 
> 

Would it (make sense|be possible) to generalize this beyond .so files
so that it can accommodate other uses in the future? The first thing
that comes to mind is that this might be useful for packages which
provide modules for interpreted languages as well (e.g. CPAN
distributions for Perl) but there are almost certainly other valid uses.

As I've understood it, this is really just a way to provide finer
dependency control and it seems that it should not be limited to
particular file types. Sorry if this is already the intention but from
what I've read of the discussion it seems that only compiled (C and
C++) shared libraries have been considered.

I've admittedly only followed the discussion loosely and have not read
through the code itself so sorry again if I've misunderstood something.

Xyne