Brock Pytlik wrote:
Step 1) validate package on client side during close
Since the server has all of the package information on close (and not
the client), how would this be done on the client-side? Why wouldn't it
be done on the server?
Of course, if we built the package on the client first and then only
sent it to the server on close after validation, you could patch all of
the actions for a given package. That would probably speed up
publishing to a remote server or certainly make it less error prone.
We might still have to perform the open on the server though since that
sets up the package's identity and performs some other checks against
the server itself.
Step 2) optional local validation on server
a) add option to depot like "--local-consistency"
What happens when the depot is restarted without the local consistency
option but there are packages left in an incomplete state?
Should control over consistency be at the depot level or the package level?
Something like: --publication-mode=strict,loose,none
'strict' being the server always checking everything, 'loose' being the
publication client tells the server whether to validate, and 'none'
performing no validation.
b) after a package has been closed, its dependencies are checked to
see if the needed packages are present on the server. If they're not,
package is placed into incomplete state. When further packages are
published, incomplete packages are rechecked to see if their
dependencies have been completed.
If we are moving towards an automated management of package state, then
we'll likely need a notification system and a way for clients to query
the repository for package state. Sort of a pkg list for in-flight
package transactions, but likely built into pkgsend.
Step 3) optional validation with other repos
...
c) depots would have a flag which determines whether someone
publishing a package to them is allowed to add additional repos to
validate against
I don't quite follow. Is the intent here to say that only packages that
depend on software from X, Y, and Z sources are allowed to be published
to this repository?
The goal is to make the framework pluggable so that it's simple to add
other dependency catchers to the program. Obvious (if not easy) ones I
can think of would be library dependencies from elf files, compression
dependencies, maybe java dependencies if that's possible, directory
dependencies (?), and probably lots more that I'm not thinking of at the
moment. The goal won't be to have all those ready for the first putback,
but to have a framework in place that makes adding them reasonably simple.
One possible snag with a pluggable framework is that it would then be
very easy for the client and server to be out-of-sync in regards to
publication behaviour.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
