Open daveschafer opened 6 years ago
Hi @daveschafer, very well documented. This was first discovered as #1190, and we verified what you are seeing back in September timeframe. We have this in the backlog to fix so it works as documented. It turns out it was a bug in NuGet.Core that wasn't respecting this setting correctly.
Hi @ferventcoder We also have this problem with different customers and can't rollout any controlled softwareupdates with chocolatey. When do you expect that this bug is fixed. thank you
@sudoturnkey I played with this months ago and I THINK if you edit chocolatey.config and change the sources to the order of your preferences, you'll get the results you want.
i.e. move your source above:
<source id="chocolatey" value="https://chocolatey.org/api/v2/" disabled="false" bypassProxy="false" selfService="false" adminOnly="false" priority="0" />
I could be wrong. Try it and see what results you get.
Assuming this works as planned...
The "official" way to do this would be to use choco to remove all the sources and then re-ad them in the order you need.
Me? I'd use a group policy to distribute the chocolatey.config file to all the computers with the settings that I'd want in it....
as long as this issue persists, you could "automatically" fix the sources by doing something like
$ErrorActionPreference = "Stop"
$cfgLocation = (Join-Path $env:ChocolateyInstall "config/chocolatey.config")
if (-Not (Test-Path $cfgLocation)) {
throw "no config found at $cfgLocation"
}
[xml]$cfgXML = Get-Content $cfgLocation
$sources = $cfgXML.chocolatey.sources
$sources.source | Sort-Object -Property priority | ForEach-Object {
$sources.AppendChild($_) | Out-Null
}
$cfgXML.Save($cfgLocation)
I am just getting into Chocolatey and bumped into this issue. After searching the net I found this report. Based on the info I found here I tried to work arround it by changing the Repo order in the chocolatey.config by removing the public Repo all together, adding my private repo's and then adding the public repo back again. As a result my private Repo's are positioned above the default chocolatey public repo in the chocolatey.config. I even gave my two private Repo's a priority of 1 and 2 and gave the public one a prio of 99. For some reason the Public repo still seems to take precedense over my privates. Am I doing something wrong or is this workarround not fixing the issue? Or could the fact that my privates are UNC based repo's have something to do with this? Thanks in advance..
@martinisoft1 No, this workaround never worked for me (or anyone else?) either. The priority and the order of repos does not seem to have an impact, Choco Repo gets choosen any way. This issue is still open and I hope that @ferventcoder takes a look at it sometime.
When I find the time I will take a look into the code.
@daveschafer I'm quite certain the workaround I've suggested above has been working for me in the past.
have you checked the contents of your chocolatey.config
file?
edit: not so sure anymore..
chocolatey.config
doesn't seem to have any effect.@daveschafer @martinisoft1 @sudoturnkey currently the best way to handle this is to remove or disable the sources that don't apply.
@daveschafer @martinisoft1 @sudoturnkey currently the best way to handle this is to remove or disable the sources that don't apply.
Well, the thing is that I do need the public repo for some standard applications. At the moment I am using a prefix for the packages in my private repo's to prevent duplicates, not ideal but good enough for now.
The thing that I find strange about the behavior is that I don't see why Choco would even know that it deals with its own Public repo. Even when I change the Prio, the Order and even the name (and yes I checked the chocolatey.config) the issue persist. One would think that in this case Choco would handle it as just an other Repo but in some way it seems to recognizie it as its Public Repo and give it the highest priority.
@martinisoft1 I don't think it is that. I think it is that it is checking all the repos instead of giving priority, I know it is in fact - I've seen the code in NuGet.Core that does this - it's a NuGet.Core code base bug.
@ferventcoder Is this issue linked to this NuGet issues?
I took a look into the code and played around with some choco commands, I think a good workaround for this problem, which I verified, is the use of the --source parameter.
# list sources
choco source
chocolatey - https://chocolatey.org/api/v2/ | Priority 0|Bypass Proxy - False|Self-Service - False|Admin Only - False.
bob - http://1.1.1.1/api/v2 | Priority 0|Bypass Proxy - False|Self-Service - False|Admin Only - False.
-----
# to install a new package from YOUR source
choco install --source=bob packagexyz
#and to update only from YOUR repo
choco update --source=bob all/packagexyz
What does not work is when you install "package X" from your source and run a "choco update" without specifying a source. The source with the newest packages gets chosen, priority does not matter here.
So like in the NuGet issue mentioned, you would need like a 'source' or 'priority' tag for every choco package seperately, to distinguish from where it should get its updates, which is kinda overkill (but a possible solution).
I hate to have this roll another release, but we have some fixes that need to get out soon and this may be a big undertaking on its own. This is something we want to get fixed sooner than later though!
Are there any news about this topic?
Maybe this will help someone who has the same issue: I have a local source on a UNC path which has the priority 1 and kept the default "chocolatey" source with priority 0. When I installed a package, the default chocolatey source was used. The reason for me was, that the version of the package was higher on the default chocolatey source, than the version of my source. The solution was to specify the version of the package and everything worked fine.
Maybe there are other issues with your source. You can check this using this command:
choco list -s \\SOMEFILESVR\networkinstallation
Hello, is there any status update on this? In my organization we really need the ability to have priority respected properly. We have the following use case:
Computers on our internal network reach out to our hosted chocolatey source via our corporate proxy. However due to COVID we have many people with laptops and VPN connections - the internal proxy does NOT work over our VPN and as such they cannot reach our hosted repo. Because we have the default chocolatey source disabled on all computers, the VPN laptops have no other source to pull from. If Chocolatey could follow source priority regardless of package version, we would be able to enable the default repo to allow laptops to reach out to the community repo while allowing internal workstations to still use our hosted repo.
It's still in the backlog if that is what you mean. It's not Chocolatey that tends to fail here, but when it hands over to nuget.core to do the resolution where it fails. So a bit more work than initially determined.
If Chocolatey could follow source priority regardless of package version, we would be able to enable the default repo to allow laptops to reach out to the community repo while allowing internal workstations to still use our hosted repo.
I'm not fully on board with going to the community repo in this way, it's not meant for organizational use for many a reason that are better served by what's laid out in the disclaimer at https://chocolatey.org/docs/community-packages-disclaimer.
However, I would see something like having an internal repo you secure and offer over the internet with authentication for your folks who are unable to work. Not to push you towards anything, but our documentation makes note of how you can do this with your organizational repos.
In regards to this 'bug' or oversight in nuget. We hit the same issue when we forked a package to use a somewhat customized installer. After we enabled priorities for our sources list, suddenly it went and installed the latest from the public repo.
Furthermore something I also think is related is it takes about 5x longer having 3 sources in our list w/priorities than it did having 3 at priority zero. Seems as if choco is diving into each individual source looking for the package to update instead of finding it in priority 1, knowing its at the latest, and moving on.
Since we use this in our puppet environment it is has caused our puppet runs to double in length ( 6 minutes to run upgrade checks on 5 packages on a 4 core Azure machine).
Seems there is certainly some improvements that could be had here.
Previous to this we used priority0 for all sources, and provided the source as a parameter to chocolatey when upgrading packages. We removed this in order to use development feed views as priority over production feed views for integration testing. This meant that to keep production and development as close as we can in code, by enabling priorities, we expected the package to be found in the first priority source (dev) and move on. In production only two sources are registered, our production and the public repo.
@chughesvf
The taking longer is definitely something for us to keep in mind as we get closer to exploring how to resolve this issue. Thanks for that note.
I ran into this issue when having a private source that requires authentication and the regular chocolatey feed. Installing packages fails because it cannot authenticate with the private feed, even the package is found on the pbulic feed. So I tried to set priorities, but without any success. Are there any news to this issue?
Can confirm this is still an issue, 4 years after issue #1190 was filed.
Perhaps it is time to remove the ability to specify "priority" until it actually works?
Perhaps it is time to remove the ability to specify "priority" until it actually works?
See this comment. The card is marked with the 'Backlog' label which means we will agree it's an issue and will prioritise and work on it when we can.
There have been some performance related problems with the changes associated with this issue (choco outdated
command taking much longer to run than normal), as such, we are going to back out the changes associated with this issue, and continue investigation on the problem.
What You Are Seeing?
If you have multiple chocolatey sources, the priority which you give them is not applied.
Quote from the Choco Wiki:
This issue happens if you have the default source set to 0 or to a higher number than your prefered source.
What is Expected?
The expectation is that every source with priority > 0 is prefered and that the lower the the priority number, the higher the priority. Nevertheless this does not seem to be the case.
Another Quote from Gary Ewan Parker regarding the default behaviour:
How Did You Get This To Happen? (Steps to Reproduce)
In this Example we have ccleaner 5.35.6210 on our own source, the public source provides the version 5.41.6446. Here you can see, that the "chocolatey" priority is set to 2 (same behaviour with 0) and our "tkcloud" source is set to 1 (lower so it should be prefered):
If we disable the default repository, the correct version from our source is selected:![2018-04-18_10h58_13](https://user-images.githubusercontent.com/36951291/38926298-777d80a6-4302-11e8-9346-a7fadd7165ef.png)
We could verify this faulty behaviour on multiple systems. Even a remove and readd of the sources does not resolve this
Output Log
On another note, the choco list commands provides the packages in the correct order:
The only problem seems to be the install commands.