Chris Quenelle wrote:
You are portraying software as either "broken" or "working" as a black
and white issue,
and I don't think it's black and white. I don't think it's obvious
that every single file in
a package must be "functional" as decided by the IPS automatic
dependency checker.
I guess I find it simpler for both the user and the developer to have a
fairly black and white issue of "broken/working." That way, we don't
have one developer deciding that it's ok for demo programs not to work
but that all library dependencies must be satisfied and another
developer making the opposite decision.
As another example, the NetBeans packages deliver small utility
binaries for a number of platforms
bundled into one large product that has identical bits across multiple
platforms. Presumably, you would
say that they shouldn't be doing that, since the dynamic linker for
Linux is not present in OpenSolaris.
I don't know much about how NetBeans is packaged. Offhand, I'd say that
you're right, I think they shouldn't be doing that and should be using
variant/facet tags to so that Linux binaries get placed on Linux systems
and Osol binaries get placed on osol systems.
There is also a larger philosophical issue about how draconian to be
with regards to automatically
detected dependencies. I can see that you are pretty far towards the
strict side of the spectrum. I
would be much further towards the loose/audit side of things. I am
only asking that we back off a little
more towards the middle of the spectrum on this issue. For example,
we could support explicit
dependency overrides that could be put in manually only when a
specific dependency was deemed to
be unnecessary by the package maintainer.
My feeling is that if we're going to do the work to put this in, then
we're asserting that strictness is necessary because either a) we've
encountered problems caused by this or b) asserting that strictness will
actually make the developer's life easier (such as if we decide we can
insert dependencies instead of erroring out).
Providing a generic override would soon become akin to all those things
that make you say yes after you've done the command. I (and most people
I'd claim) automatically and fairly blindly say "yes" b/c if we hadn't
wanted to do the command, we wouldn't have typed it in in the first
place. 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.
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
