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

Allan McRae allan at archlinux.org
Sat Aug 15 10:45:50 EDT 2009

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.


More information about the pacman-dev mailing list