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 <al...@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
