On Wed, 10 Mar 2004, Johannes Winkelmann wrote:
Hey Per,
Hi Johannes, [...]
I think having dependency listings in base and opt ports would be great. As far as I can tell, you have to introduce a path abstraction as well, or will it be necessary to specify 'contrib/libXY' where this is a valid path in /usr/ports? Path abstraction seems pretty important to be to work well with httpup repos and private ports trees.
Example: if pkgmk manages to install a dependency 'libjpeg' without knowing it's in /usr/ports/opt, shouldn't it for consistency reasons also allow doing something like cd /tmp pkgmk --package libjpeg -d -i -bd (downloading, building and installing package libjpeg with dependencies)?
To find out where a port is located my patch currently uses a PKGMK_SEARCH_PATH variable in pkgmk.conf. By default it contains something like "/usr/ports/base:/usr/ports/opt:/usr/ports/contrib". When searching for a dependency pkgmk will for each path in PKGMK_SEARCH_PATH do "find $path -path $dependency/Pkgfile" until the port is found. So, a user can add other port trees to the path list, and give them priority over other repos, etc. A "pkgmk --package xxx" feature would be possible to implement now that pkgmk knows where to looks for ports. [...]
I don't mind this addition to pkgmk since it's quite small and easy to disable. Mmmh. Recursive dependency resolving is small and easy in bash? ;-)
Actually, it's not as bad as one might think ;) /Per