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