[pacman-dev] [PATCH] add support for .so dependencies

[Allan McRae]

Christoph Schied wrote:
> Hi!
>
> Allan McRae wrote:
>   
>>> +find_sodependencies()
>>> +{
>>> +	find $pkgdir | while read filename
>>> +	do
>>> +		arch=$(readelf -h "$filename" 2> /dev/null| sed -nr
>>> 's/.*Class:.*ELF(.*).*/\1/p')
>>> +		[ -n "$arch" ] || continue
>>>   
>>>       
>> Hmmm.... not good.  Think arch=('i686' 'x86_64')
>>     
>
> This was actually brain0s idea to make this feature compatible for an
> eventually coming multilib system. It should work without problems as
> your binaries should be linked against shared objects that match your
> arch. Or is it the naming of the variables that bothers you?
>   

"arch" is a reserved variable name in PKGBUILDs.  This will break split 
package support for packages that have both binary and arch=any packages 
(which will be supported in the future).



>> Huh...  IFS?
>>     
>
> I am not sure about the IFS messing, but I think its necessary to make
> sort and uniq work.
>   

Please do not delete context.   As far as I can tell, IFS does 
absolutely nothing here.


>   
>> I'm guessing this patch was more a request for comments rather than
>> for actual consideration given a few of the issues I point out below
>> mean this will not actually work...   So I will not comment on
>> implementation at all.
>>     
>
> I don't see a problem which really prevents this approach on dependency
> generation.
>   

Well, the patch being broken and so I assume untested was my main 
issue.  I will not review a patch the submitter has not even tested.


>> As far as the idea goes, I do not like it...  This turns makepkg into
>> a bit of a black box as you can no longer see the depends and provides
>> from the PKGBUILD. 
>>     
>
> This shouldn't generate new dependencies, as makepkg already needs to
> know which packages are needed for building the package. So its a
> specialization of the already provided dependencies. If it's not, it's a
> bug in the PKGBUILD.

Well, then... what is the point?  Versioned dependencies already cover 
soname values if the package is listed as a dep in addition to is library.

Allan