On Tue, Jun 03, 2008 at 06:38:46PM -0500, Shawn Walker wrote: > 2008/6/3 <[EMAIL PROTECTED]>: > > Yes, and this is a good argument for doing it with packages and at > > publishing time. > > > > If the publishing client will computes the dependencies for > > the package, it's done once and then the manifest is published.
This assumes there is only one right way to handle a dependency. What I was suggesting is we let the client decide on the best way to solve a dependency. For example, an image might already have postfix installed which provides the /usr/lib/sendmail interface. Installing "mutt" (which has a dependency on /usr/lib/sendmail) from another repository should not need to pull down the "sendmail" package just because the publishing client thought that was the best way to handle that dependency. In essence, this is a lightweight implementation of virtual packages -- an alternative to having mutt depend on a "virtual/mta" package and have "sendmail", "qmail", "postfix", etc. provide a "virtual/mta" interface. Hey, you could even develop the whole virtual package implementation along these lines! Have each MTA deliver an /etc/pkg/virtual/mta file and have each mail client depend on that file. Voila! Virtual packages! :) (Not entirely a serious suggestion, but now that I think about it...) > > If we have to evaluate files encoded in the manifest, the pkg client has > > to do the work each time it evaluates a manifest. That doesn't scale > > nearly as well. True, and this is what I would consider the biggest drawback of the file-based dependency model. > Not to pile on with "me too"; but I have to agree. Doing it at > publication time makes consistent dependency resolution far more > likely. Well, "consistent dependency resolution" I agree with. This is what I said in my first post on this subject: | The problem with that would be that the actual package install | operation would not be predictable. Different users with | different sets of authorities would end up satisfying this | dependency in different ways. Not really sure if that is | a problem. But the same thing would happen with virtual packages too. The real disadvantage with file-based dependencies would be that dependency resolution would mean a "search" has to be issued for the file against each authority in the image, while FMRI-based virtual package dependency resolution can be carried out using the locally cached catalogs. Venky. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
