Joanmarie Diggs wrote:
On Fri, 2009-12-04 at 13:10 -0600, Shawn Walker wrote:
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.
Actually, something bad does come from it. See below.
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.
You will see other versions of those packages offered by other
publishers if:
1) they are not installed or not part of an installed incorporation;
this means that contrib and pending packages are not part of this logic
for the "not installed" case
2) they are not installed and do not satisfy the constraints of an
installed incorporation (e.g. sunw...@127 because ent...@128 prevents it)
So be relieved, because things are not as they seem here. A lot of the
filtering logic is only applied to packages that are listed in an
installed incorporation. That means that contrib and pending packages
won't be affected by a lot of the filtering logic since they're not
incorporated.
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.
We don't currently support downgrading an existing package, so there is
little point to listing the newer and older versions at the same time by
default. Nevermind that we didn't do that previously when the
publishers were the same.
There's also a significant hole in your argument for showing other
versions in that previously, the GUI did *not* show all possible
versions that you could install for a given package (same with CLI). It
only showed the newest version available from a *different* publisher of
a given package that wasn't installed.
This means that, for example, if there were three versions of Apache,
2.2, 2.2.1, and 2.2.2, you might have only seen:
pub foo, pkg Apache 2.2.2 (installed)
pub bar, pkg Apache 2.2 known
...and you wouldn't have seen 2.2.1.
So the GUI has always had a hole here that the cli does not, in that the
CLI allows you to see *all* known versions and allows you pick specific
versions to install.
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?
Because it optimises for the most common usage case. The List API
offers the following types of package lists, it is up to the client to
expose them:
LIST_ALL
All known packages.
LIST_INSTALLED
Installed packages.
LIST_INSTALLED_NEWEST
Installed packages and the newest
versions of packages not installed.
Renamed packages that are listed in
an installed incorporation will be
excluded unless they are installed.
LIST_NEWEST
The newest versions of all known packages.
LIST_UPGRADABLE
Packages that are installed and have a newer version available.
Why not instead list the package for each publisher that offers it, and
allow the client to prevent its installation as appropriate?
1) I believe most users won't be interested in those other versions
2) there is a significant performance benefit to *not* listing those
other versions in the cases where they apply
3) many users complained about the GUI listing packages that they
couldn't even install
4) we cannot determine in an efficient, quick fashion which specific
versions *can* be installed
5) optimising for the most common usage case
Please note I'm only arguing for the *default* behaviour of the GUI
being what it is now with the List API changes (LIST_INSTALLED_NEWEST).
From what I can tell, it should be reasonably easy for the GUI to offer
a view menu of some sort that directly mapped to all of the LIST types I
showed above with the default being "List Installed and Available".
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
