Dan Price wrote: > Bart and I spoke about this a bit. I see Laca's question as a symptom of > the higher-level "shopping for software" problem, and I think our cycles > would be better spent there-- on improving out metadata about which > packages represent high-level features, and which packages represent, > essentially, implementation details.
So what's a high-level feature in this particular example, and what's an implementation detail -- printing, GUI toolkit, the choices for either one, or the intersection between the two? Imagine there being packages for qt, qt/cups, and qt/papi, too. While I agree that providing interfaces for high-level software (both on the publication side and on the end-user side) is important, and probably more important than the issue Laca brings up, I don't see particularly how it's connected. What Laca's bringing up, as far as I can tell, is the lack of an interface for the intersection of major features. That is, "printing" might get you one or two choices, as might "GUI toolkit" (though that itself isn't likely to be an end-user choice; "desktop environment" would be, more likely), but the fact that you've chosen some combination might include some packages that can only work if both are installed, so it's not appropriate that either the printing systems or the toolkits/desktops depend on them. I think this could be done if we were to allow the installation of a package to enable a facet on the system, which in cases like these would mean a new (latent) dependency would be exposed, and installed. Clearly this would need some fleshing out, and there may be problems with it Bart would see offhand, having thought some more (or differently) about faceting than I. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
