On Tue, Jun 03, 2008 at 04:12:46PM -0500, Nicolas Williams wrote: > 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_.
Treating file-based dependencies as first-class citizens does so much more. > > > 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). There are two separate possibilities you mentioned here: > your repository could host meta-data for pkgs otherwise not hosted > there That wouldn't really work. If I am maintaining a "mutt" repository, I could not really be bothered keeping track of every single sendmail-alternative around (postfix, qmail, exim, msmtp, nullmailer,...) and replicating their meta-data. > or your client could query multiple repositories That's precisely what I'm saying. Just that, in this case, the server can't do anything much about resolving dependencies at publication time. My client will query my list of authorities and that could be different from what your client queries. > This non-pkg dependency -> pkg dependency resolution feature is nothing > more than an aid to package construction/publication. But it could be so much more. It could actually be a true dependency when the files being depended upon are stable interfaces. Venky. -- One hundred thousand lemmings can't be wrong. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
