On Tue, Jun 03, 2008 at 01:50:07PM -0500, Nicolas Williams wrote: > On Tue, Jun 03, 2008 at 01:41:03PM -0500, Shawn Walker wrote: > > 2008/6/3 Nicolas Williams <[EMAIL PROTECTED]>: > > > On Tue, Jun 03, 2008 at 09:29:19AM -0500, Shawn Walker wrote: > > >> Since the dependency could be resolved at publish time (i.e. the file > > >> dependency is resolved to a package name at that time), I don't think > > >> those concerns apply. > > > > > > I agree. One thing that comes to mind is that at the time of resolution > > > of the file dependency to a package name there could be many possible > > > matching packages, so some control over the resolution process may be > > > required. > > > > To me, it would be easiest just to do something like: > > > > 1) find packages for /path/to/file > > > > 2) if more than or less than one, fail > > or prompt. > > > 3) if exactly one, use matching package name > > right. > > > However, one problem with this is that it creates a situation where > > you are publishing a package that depends on a file in a package that > > hasn't been published yet. > > fail.
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. > > That makes me think that we need the ability to defer some operations > > until the server rebuilds the catalog. Won't help. It could be provided by a different repository. Just letting it go through and having the client handle it would probably be best. 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. Venky. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
