Brock Pytlik wrote:
Shawn Walker wrote:
Brock Pytlik wrote:
Shawn Walker wrote:
Greetings,
The following webrev contains changes and fixes for the following
issues and RFEs:
5872 List APIs required
12929 image.py:get_publisher_ranks can traceback after older
client configuration changes
12946 pkg list should provide way to list only newest versions of
all packages
webrev:
http://cr.opensolaris.org/~swalker/pkg-list/
[snip]
High level comment, I'm not sold on the idea of "
Packages that do not apply to the current
image (such as those for a different architecture or that are
not applicable to the current zone type) will never be listed.
"
I'd kinda like an option to say, no, I really mean ALL packages.
Mostly, I'm thinking about a case where a user has two images in two
different situations (one on sparc, one on x86 or one that's a global
zone and one that's a non-global zone) and one is just really
hosed and they're trying to use the other to gather information about
what packages are available that might be missing.
So you're ok with architecture filtering, but not zone variant
filtering then by default?
I'm of the belief that most users are not interested in packages that
are not for their image variant by default.
However, I did make it so that its trivial to include packages not for
the current variant with the API.
I could easily add a command-line option that causes the cli to
include variant packages. Would this suffice, and if so, what should
that option be?
I'm fine with everything you're doing by default. All I wanted was a way
for a user to get all the packages, regardless of variants/applicability.
As for what the option should be, I don't really care much. We've used
the obvious ones like -a, -v. One possibility would be -V. Whatever you
decide is fine, I'm not going to bikeshed the letter choice.
-a never meant all anyway unless combined with -f. Would it be
sufficient to include all variants when -f is used instead of
introducing a new option?
client.py:
I'm not sure the division between client and api here is quite right.
I think more of the logic here should be moved into the api.
For example, the items on lines 294-308 I would think should be
within the logic for get_pkg_list? Wouldn't the gui want to refresh
when the cli would?
I tend to disagree here. The API provides a refresh function, and
adding a refresh function to get_pkg_list would then require a
transport lock. Since clients can simply call refresh() themselves if
they so desire, I saw no need to combine two different API functions.
And actually, no, the GUI actually wouldn't. I suspect different
clients have vastly different refresh behaviour. For example, the GUI
refreshes on startup and various other places after operations
complete and so on. It also triggers refreshes through the
updatemanager.
Ok, then can we call the api refresh instead of img.refresh? (though it
sounds from what you've said below that you've already done this)
Yes, I've done that already.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
