portfile: "depends port:xxx" broken for port pkg foo

[izmir@…]

After compiling everything with "port pkg foo -v", I install from the package, and "port clean foo".

gettext:

Tried gettext next: "port pkg gettext -v" - kept extracting libiconv again.

deteting the line "depends_lib port:libiconv" from the gettext portfile got port to see the already installed libiconv. In fact, libiconv is the ONLY thing I did have installed.

---

render depends:

"port pkg xrender -v" started compiling pkgconfig (for the second time), even though it is installed. render (the portfile) contains this:

depends_build port:pkgconfig

So deleting that line lets render compile alone, and it makes its little render.pc file to satisfy the xrender depenency.

---

freetype issue:

"port pkg freetype -v" starts zlib compiling again (its already installed). Removing "depends_lib

port:zlib" gets past it.

---

fontconfig

after having installed expat and freetype with "port pkg xxx -v", and doing a port clean xxx or manually trashing the workdir, fontconfig (yes, once again...) goes for expat and freetype again. Deleting the depends_lib line, (yes once again...) does the job.

---

Xft2

problems again with port:foo (all 3)

[jberry@…]

Hey Anax,

Thanks for reporting this problem. Frankly, I don't know enough about the pkg target to know whether it's a real problem, whether it's expected, and whether it even has anything to do with the port dependency.

If somebody who knows the pkg target could comment, that would be great.

I wonder also if you could try a similar test case, but instead of simply removing the dependency, convert it into a lib:XXX:portname dependency from a port:portname dependency.

These two dependencies are handled in a similar fashion, so understanding whether they result in the same behavior, or not, might be illuminating. The port:portname dependency is handled by a function that always returns false (and which causes the dependency to be evaluated based on the registry of installed ports). The lib:XXX:portname dependency is handled by a function that returns true if the library is found, and false otherwise. Since XXX should always be missing false (and thus cause a false return), these two should result in the same behavior.

But there may be another problem somewhere in handling of the port dependency. We've found several problems having to do with parsing of the dependency field, since this dependency introduces a new "two-field" form of dependency. This could also be at work here.

Thoughts, anybody? If I knew more about pkg...

-jdb

[izmir@…]

When these dependencies fail, it gets worse. It extracts, and compiles again, and packages up a foo.tgz in /opt/local/var/wherever, and then it tries to install. It comes back with:

---> Archive apr-0.9.6_0.powerpc.tgz packaged ---> Archive for apr 0.9.6_0 packaged ---> Installing apr 0.9.6_0 ---> Activating apr 0.9.6_0 Error: Target com.apple.activate returned: Image error: /opt/local/bin/apr-config already exists and does not belong to a registered port. Unable to activate port apr. Warning: the following items did not execute (for apr): com.apple.activate Error: The following dependencies failed to build: apr

And that error doesn't lead you back to a depends problem in the portfile.

---

But a lib:XXX:portname can still exhibit identical erroneous behavior. Another example: apr, apr-utils & subversion. apr installs fine. subversion calls for "depends_lib lib:libapr-0.0.9.5:apr" and apr-utils does a more generic "depends_lib lib:libapr-0.0". "port pkg subersion" would work if I had THAT specific version of the libapr, but the portfile wasn't updated, and so I have 0.9.6 installed (even better, you would think). But I don't have 0.9.5, so it tries to compile apr AGAIN, which fails with to install with an error (the one above).

So if any dependency fails (and it already installed via an Installer.app package), then any error in the dependency declaration will cause another failure - which doesn't immediately lead back to a versioning error.

Another example with identical outcome is "lib:foo:foo". Some portfiles still exhibit this (I just installed everything from scratch on Tiger, but I just changed portfiles as I went along). The depends here needs to be "lib:libfoo:foo". The other types of depends (bin, path) aren't a problem. Although... p5-xml- parser didn't explicitly call for perl5.8 in the portfile, and yet it went about installing it, but I take that as a "darwinports policy" kind of install.

If a dependency were valid (the right library version..., capitalization...) then lib:XXX:foo works. As an example for subversion: "lib:XXX:apr". This WORKS.

It FAILS in this example from subversion if I change "lib:libaprutil-0.0.9.5:apr-util" to "lib:XXX:apr-util". The library is "libaprutil-0.0.9.6.dylib". Note the missing "-" hyphen.

A simple (though potentially inaccurate) fix would be to check if there is a foo.pkg receipt in /Library/ Receipts. There doesn't seem be any other database in the /opt/local/var/db/dports folder. Perhaps, installing a receipt in the dports/receipts folder might also be looked at.

This could be another manifestation of a lack of an all-encompasing database for the ways of installing that darwinports supports.

[jberry@…]

This bug is old, and near as I can tell it reflects common issues with installing ports, and nothing in particular relevant to the port: dependency.

Resolving as "worksforme".