Here is an interesting and probably common scenario:
Let's say there's a large application which includes lots of
miscellaneous binaries
and scripts, which might not be used by most users. For example, let's
say it includes
a perl script in a 'demo' directory as an example of how to use a perl
API that it exports.
In this scenario, it seems like the perl package should not be a
required dependency.
In general, there should probably be a way for packages to be able to
override
the automatic dependencies when they need to. In fact, some of these
dependencies
might be better treated as "audit-style" checking, more like lint rather
than hard-wired
into the package creation process. Then you could have hooks to enforce
a specific
audit policy on a per-repo basis. For example, the 'contrib' repo might
want a different
audit policy than the 'release' repo.
--chris
Brock Pytlik wrote:
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
