Greetings all, based on a conversation with sch I had last week, I
thought I'd put together some thoughts and plans for improving
pkgsend/publication for the next release. What's below is very
preliminary, but is a high level view of what I think the necessary
steps are to get where we want to be. Please let me know what areas I've
missed in addressing or if you think a direction I've outlined isn't useful.
Step 1) validate package on client side during close
a) check all files for "known" implicit dependencies (see below)
b) check whether the dependencies from the files/groups/users are
satisfied by the transitive closure of the declared dependencies
c) abort the transaction if dependencies aren't satisfied. Try to
provide the user reasonable info about what files caused the problem and
what packages would fix the issue.
Step 2) optional local validation on server
a) add option to depot like "--local-consistency"
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.
c) This option is primarily for servers storing an entire distro
(dev, release, for example)
d) (optional) server would also check implicit dependencies like
the client does above and will place a package with an undeclared
implicit dependency into an incomplete state. Probably should only do
this if there's a way to inform the publisher as to what's happened.
Step 3) optional validation with other repos
a) like step 2, except that it is allowed to take other repos into
account when validating a package. An example would be extras (or
pending, or contrib) to allow those to check the existence of their
dependencies at publication time against known distro repos.
b) pkgsend would be augmented to allow a user to tell the depot
what other repos to validate against
c) depots would have a flag which determines whether someone
publishing a package to them is allowed to add additional repos to
validate against
d) depots could be optionally configured to use certain repos to
validate against
Step ?) Allow client and server to validate against an incorporation
instead of either what's installed on the client or what's present on
the server. (Labeled as ? since it could come anytime after step 1 for
the client at least)
Step ??) Allow dependencies to be expressed on files, groups, users, and
links, instead of on packages and have either the client or the depo do
the conversion at publication time. (Labeled as ?? since I'd like to do
this client side as part of step 1 but I want to keep the wads of
reasonable size and I think there may be some complixity with this idea
and creating new mutually dependent packages which express their
dependencies in this manner.) This is roughly what I think of when we've
talked about publishing against an incorporation in the past.
"known" implicit dependencies:
The first step would be to catch what I'll call #! dependencies. The
idea is to use the #! at the top of py and other similar files to catch
a dependency on python (for example) or ksh, etc.
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.
Thanks for taking a lookm
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
