Greetings,
What follows is a short proposal attempting to address current issues
surrounding listing packages in light of package renames and
ugpradability indication.
1. Overview
============================================================
While working on the new client List APIs, it has become clear that
renamed packages and 'upgradable' packages present interesting
challenges. What follows is my attempt to summarise what the likely
usage cases are to account for, and proposed implementation or
challenges (if any) surrounding implementing the requested functionality.
Each section below enumerates what the existing usage cases are
(believed to be), proposed changes, and challenges or unresolved issues
(if any) related to the functionality.
1.1. Installed Case
------------------------------------------------------------
The user has requested a list of all installed packages. This is
regarded as the most common case.
1.2. All Case
------------------------------------------------------------
The user has requested a list of all versions of all packages.
Currently, only pkg(1) offers this (as far as I know), using this command:
$ pkg list -af
1.3. Newest Case
------------------------------------------------------------
The user has requested a list of the newest versions of all packages,
regardless of incorporation, etc.
Currently only offered by 'pkgrecv -n'.
1.3.1 Proposed Changes
Add a '-n' option to 'pkg list' that displays only the newest versions
of all packages (that are not obsolete or renamed).
1.4. Available Updates Case
------------------------------------------------------------
The user has requested a list of packages with updates available.
Currently, the output of pkg list here only lists packages that have a
newer version available, and does so ignoring publisher "sticky"-ness,
incorporations, etc.
The information returned here is currently exposed in pkg(1) via:
$ pkg list -u
...and the version information is shown in the packagemanager GUI in
some places.
This functionality is also pratially provided via pkg(1) using:
$ pkg list -a
...which will show the installed version of a package and the newest
version available of every package (regardless of installed status).
1.4.1 Challenges
There are several:
* The current upgradability indicator is often wrong since what version
of a package will be upgraded to can't be answered by simply looking
for the newest version of a package stem. The only accurate way to
determine upgradability is by using the solver.
* The current upgradability evaluation is based on the presence of a
newer version available, without accounting for renames,
incorporations, obsoletions, or publisher "sticky"-ness.
* It is believed that users have two different kinds of upgradability in
mind: distribution, and those applicable for the currently installed
set of incorporations (think apt dist-upgrade vs. upgrade). The
current result set satisfies only the distriubtion case and does
not do so accurately.
1.4.2 Proposed Changes
Several options:
* Retain 'image-update'; add a new 'update' subcommand that only
attempts to update installed packages with the same command-line
options as image-update but bounded by the currently installed
incorporations. Remove -u (and the 'U' column) in favour of the
'-nv' options of this new subcommand.
* Rename 'image-update' to 'dist-update' retaining its current
behaviour. In addition, implement the first option above.
* Enhance image-update to deal with both the distribution upgrade
and installed package upgrade case. Add a separate subcommand
that is strictly for checking for updates and that has output
similar to pkg list. Remove -u and the 'U' column from pkg
list output. Suggestions for appropriate command-line options
to image-update welcome.
* Retain the -u and the 'U' column of pkg list, but base its
information on the cached result of one of the above commands
or (least favoured option) pre-compute it during pkg refresh.
1.5. Installed + Available Case
------------------------------------------------------------
The user has requested a list of all installed packages and any packages
that are available for installation (not installed).
This functionality is currently provided (roughly) via pkg(1) using:
$ pkg list -a
...which will show the installed version of a package and the newest
version available of every package (regardless of installed status).
The packagemanager GUI also provide this list to the user by default.
1.5.1. Challenges
There are a few:
* A single package may have been renamed multiple times, and so
determining which package stems do not have a version installed
requires crawling through all available package versions dealing
with each possible range of rename operations. This is slow to
say the least (at least in terms of listing packages). Although,
performance should only be an issue for users that are behind
significantly with some trickery.
* What version should be shown to the user as being available for
install? The set of packages that *can* be installed isn't
actually known until the solver is executed. However, in light
of repositories such as pending and others, pre-computing this
information seems unlikely.
1.5.2. Proposed Changes
Leave the cli/gui to show all installed versions as they do today.
However, when showing available packages:
* find first rename after the currently installed version for
each package and its new name
* retrieve the newest available versions of all packages
* use the list of initial renames above to eliminate entries from
the list of available (not installed) packages
* show the merged result of the installed + newest available
This does mean (as today) that a user may see the information for a
newer version of a package than will be installed.
1.6. Obsolete/Renamed Case
------------------------------------------------------------
Currently, the cli will indicate packages that have been renamed or are
obsolete. However, these packages are likely to not be of interest to
most users unless they are installed.
1.6.1. Proposed Changes
It is proposed that obsolete and renamed packages (that are not
installed), would not be included in any package listings by default.
The determination of renamed/obsolete would be based on the newest
version of each package.
The client List API would provide a way to include these packages if so
desired. In addition, the 'pkg list' subcommand could be enhanced to
optionally include these either by adding a new option or by always
including them when using '-a', as an example.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
