Chris Quenelle wrote:
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
I think to some extent, this is a philosophical issue, what it means for
a package to "work" or "be complete." While I see your point about the
frustration or inefficiency of having to add a dependency on perl in
that case, I also see the point of view that if we install a package,
everything in that package should have all its dependencies met. In the
case you outline above, I would suggest that the right thing to do would
be to break the demo pieces out into a separate package(s) which had
additional dependencies. As an end user, if I install X, I think I have
the right to expect everything in that package to "just work."
I'm don't agree with allowing an override of the auto dependencies. I
could be wrong, by my expectation would be that while we might have a
large number of false negatives (missed dependencies) the number of
false positives would be small (given the expectation I outlined above).
I'm not sure why the release repo would want a different audit policy
than the contrib repo in any case. I tend to be of the opinion that we
shouldn't deliver software we know to be partially broken in terms of
dependencies.
Brock
[snip]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
