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

[matthewbruenig at gmail.com]

When I worked on zenwalk's buildpkg which is basically a port of makepkg,  
we had something like this to find dependencies. It is painfully slow on  
applications of any significant size. Not a good idea.

On Aug 15, 2009 9:45am, Allan McRae <allan at archlinux.org> wrote:
> 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