Brock Pytlik wrote:
> If, instead, you're asking for overrides for specific dependencies,
like pkgsend claims you must depend on a, b, and c, and the package
maintainer is has to add "undepend a" "undepend b" and "undepend c" to
their manifest, then I have slightly less concern. I still don't like
the idea though.
Just to be clear, that's exactly what I was suggesting. It would only be
used if the package supplier determined that one of the automatic
dependencies was incorrect. Since I have no immediate problem that needs
solving here, I don't have a real stack in this at the moment. I just
wanted to raise the issue. It seems easy enough to add an "undepend"
feature later if this becomes a problem.
--chris
I'd like to see some more compelling reasons/examples for why moving
from the stricter side is needed. I think the example you gave earlier
doesn't bother me because my answer is that if minimization is
important, fix the packaging, if it's not, just add the dependency, or
simply delete the problematic demo.
Brock
--chris
Brock Pytlik wrote:
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
