On Fri, 2009-12-04 at 13:10 -0600, Shawn Walker wrote: > Now the details (a package is not listed if): > > 1) it is for a variant that does not apply to the image (think SPARC > packages on i386 systems and vice-versa, zone packages, etc.)
I totally agree that this makes sense. > 2) it is not installed, and is simply the older name of a package > already installed (think SUNWvim getting renamed to vim, and you have > vim installed, therefore no reason to list SUNWvim) and it is part of an > installed incorporation (such as entire) Ditto. > 3) it is not installed, and is the newer name of an installed package > (you have SUNWvim installed, which has been renamed to 'vim' in a newer > version) Ditto. In all of the above cases, it does seem that what is being omitted from the list is irrelevant to me as a user. > 4) it is another version of a package that is already installed, because > only a "install -nv" or "image-update -nv" knows what version *can* be > installed. Here's where we don't see eye to eye, I'm afraid. :-) *Something* knows what version *can* be installed. And that something will prevent me -- if appropriate -- from installing a package should it be in my list and I attempt to install it. So nothing bad will come from listing a package which might very well prove to be installable. On the flip side, by failing to (continue to) list it in PM, you're significantly reducing the potential for discovery of a package which might be needed. I have vague recollections from a while ago in which Contrib and Pending each had a version of .... I want to say Opera, but it might have been a different package. Anyhoo, the names and versions were the same. But the package offered by one of the publishers had an unpleasant habit of segfaulting whereas the other, it turned out, did not. Right now, under such conditions, if I were to view each of the publishers in question in PM, I'd see that each offered this package. As such, I might then be able to solve my segfaulting problem by attempting to install the package offered by the other publisher. The same can be said for modified versions of a particular package offered, say, to implement a bug fix prior to the fix being released to the public. If such a package is not currently installable due to constraints from the entire incorporation, and if I know that the package is compatible with my system, I can always republish it under a different number. Assuming I know the package is there in the first place. Once PM switches over to the list API, it will no longer be the case that one can discover these packages unless the publisher modifies the version number to ensure that it's later than the installed version but still falls within the version numbering constraints established by other packages and incorporations, correct? If so, post-9519, in order to discover that an alternative instance of a package exists -- and optionally install what may be a perfectly-installable and needed package -- a PM user will likely be forced do one of the following: * Switch to the cli * Switch to the web interface * Uninstall the current package (if possible given existing constraints) again, assuming that he/she knows that it is necessary to do so and takes the time to do it. How does that improve the user experience? Why not instead list the package for each publisher that offers it, and allow the client to prevent its installation as appropriate? --joanie _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
