On Wed, Jun 04, 2008 at 02:35:02AM +0530, Venky wrote: > I must be explaining myself very badly. Let me try again. I see no > reason why there needs to be a translation of file-based > dependencies into normal dependencies *at publication time*. (If > you can come up with a reason, please let me know.) The server, in > fact, should not even care about the specified dependency. It is up > to the pkg client to resolve it.
The reason is: it's a tool to make it easier for package developers, which in turn means: more likely that they will record certain dependencies. The ELF dependency resolver certainly adds value. It's just much harder to do the same for shell scripts. But at least a pkg developer might be aware of dependencies on uncommond things (e.g., not fileutils, ...) and record _that_. > PS: If you read the rest of this thread, you will find one of the > examples I mentioned earlier about "mutt" depending on > "/usr/lib/sendmail". That is the example I was using to make my > point that resolving dependencies at publication time does not > make sense. You'd written: |Not really. If I am hosting a repository which provides the "mutt" |package, I would rather not be forced to host "sendmail" or |"postfix" also. I don't think you necessarily have to host those pkgs just so the dependency on /usr/lib/sendmail can be resolved; it suffices that there be a way to find the relevant meta-data (your repository could host meta-data for pkgs otherwise not hosted there, or your client could query multiple repositories). This non-pkg dependency -> pkg dependency resolution feature is nothing more than an aid to package construction/publication. Divorce it from publication if you wish, and make it a standalone tool for developers to use at their discretion, to satisfy curiosity as well as to help them work out proper dependencies, and even not at all. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
