Bugzilla – Bug 2253
With the latest build of the pkg repo, can't install packages from additional authorities
Last modified: 2008-07-17 11:17:20 UTC
You need to log in before you can comment on or make changes to this bug.
Building the pkg repo and then installing the resultant pkg package results in not being able to install packages from additional authorities. For instance, with a /var/pkg/cfg_cache configured thusly: [policy] require-optional = False display-copyrights = True preferred-authority = opensolaris.org pursue-latest = True [filter] [authority_opensolaris.org] origin = http://osol-re.sfbay:80/ ssl_key = None prefix = opensolaris.org ssl_cert = None mirrors = [] [authority_punchin] origin = http://righthook.east.sun.com:10000/ ssl_key = None prefix = punchin ssl_cert = None mirrors = [] I am unable to install any packages contained in the punchin authority. While pkg list -a shows the packages, pkg install of those packages gives: pkg: no package matching 'SUNW0punchin' could be found in current catalog suggest relaxing pattern, refreshing and/or examining catalogs No amount of refreshing the pkg catalog helps. Installing an older version of the pkg command (something built on May 27th or thereabouts) does not exhibit this problem. Looking vat /var/pkg/catalog/punchin/catalog I can see the packages as well. cat /export/home/glagasse/proto/var/pkg/catalog/punchin/catalog V pkg SUNW0punchin 2.2.0,5.11-1:20080604T182710Z V pkg OPGpunchin 1.2.0,5.11-1:20080604T182744Z V pkg ITpunchin 1.2.0,5.11-1:20080604T182746Z V pkg SUNW0punchin 2.2.0,5.11-1:20080604T182750Z V pkg OPGpunchin 1.2.0,5.11-1:20080604T182850Z V pkg ITpunchin 1.2.0,5.11-1:20080604T182852Z V pkg SUNW0punchin 2.2.0,5.11-1:20080604T182855Z V pkg SUNW0punchin 2.2.0,5.11-1:20080604T184121Z V pkg SUNW0punchin 2.2.0,5.11-1:20080604T184252Z V pkg SUNW0punchin 2.2.0,5.11-1:20080604T190303Z
This looks to be related to the change made for bug 2230. The test_basics_1 (cli.t_twodepot.TestTwoDepots) test fails when using a version of pkg where the fix for bug 2230 has been applied. Once I remove the change for 2230, it succeeds.
Did you try specifying the pkg authority as part of the install command? eg pkg install pkg://punchin/SUNW0punchin
No, I didn't try specifying the authority to the install command. Should I have to? If so, that would be a change from previous behaviour.
(In reply to comment #3) > No, I didn't try specifying the authority to the install command. > > Should I have to? If so, that would be a change from previous behaviour. Would you be kind enough to try it out and report back the results? Thanks.
specifying the authority name does indeed allow the package to install. I used: pkg -R /export/home/glagasse/foo install pkg://punchin/SUNW0punchin This isn't expected behavior though is it?
(In reply to comment #5) > specifying the authority name does indeed allow the package to install. > > I used: > > pkg -R /export/home/glagasse/foo install pkg://punchin/SUNW0punchin > > This isn't expected behavior though is it? I'm not certain -- Bart is better suited to answer that question. *However*, since your preferred authority is opensolaris.org, not punchin, what do you expect as a user if you ask for a package that isn't available from your preferred authority? Should it try each of your available authorities until it succeeds? What if it is available from multiple authorities?
Yes, I'd expect it to search all of my available repositories. As for handling the case where it's available from multiple authorities, it should 'figure it out' and 'do the right thing'. Now, what that right thing is is a good question. If it can't figure it out on it's own, then display a message to that affect and tell me what it found and how I can specify explicitly what I want based on what it found. Naturally, if it finds a match in my preferred authority then there isn't much left to do as I would expect it to be installed from there.
Indeed, we want to get to the "do the right thing" stage. Right now, however, the design for handling packages from different authorities is rather different than the implementation.... It appears we may have a regression in behavior w/ multiple repos for a bit while we get some underlying code fixed.
johansen suggests that bug 2325 and bug 2347 could be closed as dups of this one, but while those two share a stack trace in common with bug 2229; namely, that the package it's complaining about isn't a full package fmri, but is missing the timestamp. This bug doesn't have such a stack trace, though there might be one associated with it. If so, please 'fess up.
I'll note that bugs 2325 and 2347 both have a build version component of the version, while bug 2229 didn't, so that's likely a different problem, indeed. This bug also has more to do with installing packages from alternate authorities on the commandline -- that if a package isn't found in the preferred authority, it should be pulled from another one automatically, rather than having to specify an authority (in fact, doing that does work). So I'd say that 2325 and 2347, while possibly dups of each other, are probably not dups of this bug.
Or maybe it's just that we're hitting the same problem through two different codepaths, one of which results in a stack trace, the other we're handling a bit more sanely.
*** Bug 2392 has been marked as a duplicate of this bug. ***
Resetting target to Build 94. Marking FIP as I know Bart is working on this.
*** Bug 2325 has been marked as a duplicate of this bug. ***
*** Bug 2347 has been marked as a duplicate of this bug. ***
Fixed in changeset 5c756997bf679d4c20152406180122e722332237.