On 09/21/11 15:18, Danek Duvall wrote:
I'm trying to track down why Rafael's machine isn't updating the way he
wants, and in the process have run into a pair of UI issues that seem a bit
weird to me. One is the following:
# pkg update -nv \*@latest //userland/system/data/timezone@latest \
//userland/system/data/hardware-registry@latest \
//userland/service/network/ftp@latest
pkg update: The following different patterns specify the same package(s):
//userland/system/data/hardware-registry@latest, *@latest:
system/data/hardware-registry
*@latest, //userland/system/data/timezone@latest: system/data/timezone
*@latest, //userland/service/network/ftp@latest: service/network/ftp
He's running a build 174 pkg5-nightly, though I didn't get the actual pkg
version. Didn't we solve this problem recently, or at least a variation of
it?
You're thinking of how we made 'pkg install' and 'pkg update' account
for --reject.
We've talked about fixing the pattern matching so you can combine more
specific and more generic patterns, but I don't think we have an RFE
filed yet.
The second is this:
pkg contents -rH -t set -o pkg.shortfmri,value \
-a name=org.opensolaris.consolidation \
system/data/[email protected].{165..173}
(where that bit with the curly braces means pretty much what you'd expect --
put each number in that sequence into that word, each time as a separate
word on the commandline). The result is somewhat unexpected:
pkg://solaris/system/data/[email protected]
userland
Yes, that's expected. pkg info -r and pkg contents -r have both worked
that way for quite a while now, whether they should is another matter.
They only return the newest version matching the patterns provided. pkg
list -n works the same way.
Someone would have to sit down and think about the pattern matching
implications and then come up with a set of rules.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
