chocolatey-archive / puppet-chocolatey

Chocolatey package provider
Apache License 2.0
88 stars 134 forks source link

DotNet4.5 keeps showing up as a change even if it's already installed #19

Closed mendhak closed 10 years ago

mendhak commented 10 years ago

I posted this on SO but figured I should ask here as well in case I'm doing something wrong.

I am trying to ensure that .NET 4.5 is installed on an agent. I am using the puppet-chocolatey provider:

package { 'DotNet4.5':
    ensure          => installed,
    provider        => 'chocolatey',
}

However, each time I run it, the log shows 1 change:

Notice: /Stage[main]//Node[mymachine1234]/Package[DotNet4.5]/ensure: created

Even though .NET 4.5 is installed, it still reports that 1 change has occurred as shown above.

I have also tried the value of 4.5 instead of installed in the definition above, but whatever I apply it reports 1 change.

In contrast, when I use the same thing to ensure Node.js is installed, it works just fine and doesn't report 1 change each time.

ferventcoder commented 10 years ago

Thanks for reporting this. I mentioned on SO that I thought it might have to do with the way we are getting back DotNet4.5, but stripping off the .5 so it looks like DotNet4 and so we are trying to rerun the installer. The good news is the package won't reinstall but you will get hit each time with an out of sync so it shows up in puppet reports like something is happening.

rismoney commented 10 years ago

what do you get when you run

chocolatey version all -lo | findstr /V "^name +found" | findstr /V "^--- + -----"

break it down by running first command in pipe then add second

i have to ask, but are you running latest chocolatey and latest provider?

mendhak commented 10 years ago

Yep, fresh and new installation of puppet, chocolatey and puppet-chocolatey.

I get the following when I run that command:

DotNet4                                 5.4.5.20120822
nodejs                                  0.10.25
nodejs.commandline                      0.10.25

When I saw that version number I then tried

package { 'DotNet4.5':
    ensure          => '5.4.5.20120822',
    provider        => 'chocolatey',
}

That produces a different error:

Error: Could not update: Execution of 'C:\Chocolatey\chocolateyInstall\chocolatey.cmd install DotNet4.5 -version 5.4.5.20120822 ' returned 1: Chocolatey (v0.9.8.23) is installing 'DotNet4.5' and dependencies. By installing you accept the license for 'DotNet4.5' and each dependency you are installing. Unable to find version '5.4.5.20120822' of package 'DotNet4.5'.

@ferventcoder - Indeed, right now it doesn't reinstall but does show up as a change on each run in the Puppet Dashboard.

rismoney commented 10 years ago

it looks like a parsing error. it might be in chocolateyversion.what do you see with just

chocolatey version all -lo is the name showing dotnet4 or dotnet4.5. what name do you see in c:\chocolatey\lib

rant:why couldnt the guys on .org just name packages properly... its just dotnet and leave semantic versioning to the version. i understand x64/x86.

mendhak commented 10 years ago

Ah with ensure => installed and the chocolatey version all -lo command, it's showing up as DotNet4 not DotNet4.5! I should have noticed that earlier.

name                                    found
----                                    -----
DotNet4                                 5.4.5.20120822

In C:\Chocolatey\Lib, it corresponds to this folder:

C:\Chocolatey\lib\DotNet4.5.4.5.20120822

So the 4.5 is repeating, I see what you're talking about now. It should probably be called just DotNet.

rismoney commented 10 years ago

the problem is its not easy to determine from that file folder name (which iirc is how cver works), what the version is...

in fact i know of no sane way, given that particular package name, to tell where the name ends and the version begins. Any logic applied to that name would be a hack.

I might boo to the choco folk who pushed that one... The alternatives I see are 1. re-write the versioning tool to inspect the xml in each lib subfolder, which only makes it slower, 2. put an separator character in the lib folder names, that cannot be part of the package name.

Neither of which are going to help you on your shor term fix. To fix your issue, might involve you hacking your local lib to a sane name... Or we can get the author to just push the package as dotnet instead.

ferventcoder commented 10 years ago

I tell you what @rismoney - switch over to choco list -localonly and it will be separate with name of package and then version

ferventcoder commented 10 years ago

And it will be ten times faster. Cuz right now it's sloooooooooooowwwwwwwwwwwww. Did I mention that it's slow?

ferventcoder commented 10 years ago

This should give you an idea what I mean:

roundhouse 0.8.5.0
ruby 1.9.3.44800
ruby.devkit 4.5.2
Sake 0.1.3
scriptcs 0.4.0
setaffinity2 1.41
SkyDrive 16.4
skype 6.5.0.158
sqlite.analyzer 3.7.8.0
sqlite.shell 3.7.8.0
sqliteadmin 0.8.3.2
SqlServerExpress 10.0
StatLight 1.6.4375
stexbar 1.8.3
structuremap 2.6.2
SublimeText2 2.0.2.2221
SublimeText2.app 2.0.1.22171
SublimeText2.PackageControl 1.6.3
SublimeText2.PowershellAlias 0.1.0
synergy 1.3.8
sysinternals 1.2012.05.14
testnamingmode 1.0.1.2
TinySpec.NUnit 0.9.0
toggl 4.73.0
tortoisesvn 1.7.7
ultramon 3.1.0
ussf 1.5.0
virtualbox 4.2.6.20130130
VirtualCloneDrive 5.4.5.0
visualcplusplus2008sp1 1.0
vlc 2.0.2.20120713
warmup 0.6.5.0
WebActivator 1.4.1
webpicommandline 7.1.1374.20120226
Wget 1.11.4.1
wifi-manager 0.1
windirstat 1.1.2.1
windowpad 1.60
Wix35 3.5.2519.20130612
rismoney commented 10 years ago

@mendhak how does that command choco list -localonly display the Dotnet4.5 package?

@ferventcoder whoa! and thats easier to deal with... coolness. not sure when I am going to get a chance to update the provider, my plate is fairly full atm.

ferventcoder commented 10 years ago

I might have some time. It will provide a huge perf boost. :)

wscheele commented 10 years ago

i have the same problem with ruby1.9 which is morphed into ruby1 when checked against

chocolatey version all -lo

is there a workaround to prevent the 'always apply change' effect?

wscheele commented 10 years ago

i did a quick fix using list -lo instead of version all -lo available in the pull request. the only thing i ran into is that i had some case sensitivity issues with the differing output, which were easily resolved by changing the package title and adding an alias. the fix does prevent the apply change ad nauseum

ferventcoder commented 10 years ago

We just merged @wscheele's changes and a few more changes that made the specs pass. Merged into master at cca5946c43a7a536c261a5d88e7f065474ea69f9