Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for both 32 and 64 bit versions of vvvv #4

Closed
ccoenen opened this issue Jan 16, 2013 · 6 comments

Comments

@ccoenen
Copy link
Contributor

commented Jan 16, 2013

Beta 29 (and probably future versions as well) are available in both 32 and 64 bit. I am relatively new to chocolatey, so i'm somewhat unsure how to add this to the packages. But it would be awesome to support both architectures.

@smakhtin

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2013

I checked StackOverflow and people saying:

We've been discussing a similar issue on the Chocolatey Google Group. There aren't any semantics built into NuGet. The requirement wouldn't be, what processor architecture are you running on. It would have to be what processor architecture is your project targeting. And then that complicates things... you'd have to understand AnyCPU as well.

I think for now, I'm going to upload two packages. I can always published a combined one when I fix up an install.ps1 that can handle querying the project target.

mypackage.x86
mypackage.x64

So we should have two separate packages, one for x86 version and one for x64. What do you think? Should we just create vvvv.x64 package? Or also rename current to vvvv.x86. From my side, i think the easiest way is to keep more actual version (currently it's x86) in vvvv package and create package vvvv.x64 for experimental version. When x64 become stable, we should just replace files in vvvv package, so it's became x64 and create a special package for vvvv.x86. Then we could delete vvvv.x64 or link it to vvvv for backward compatibility.

@ccoenen

This comment has been minimized.

Copy link
Contributor Author

commented Jan 17, 2013

i think, having both (vvvv.x86 and vvvv.x64) would be good. vvvv itself could then be a virtual package or dependency pointing to vvvv.x86 for the time being.

@smakhtin

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2013

Yes, sounds smart. I will make this to packages after the lunch )

@smakhtin smakhtin closed this Jan 17, 2013

@ccoenen

This comment has been minimized.

Copy link
Contributor Author

commented Jan 19, 2013

I think, the name.64 naming is a little off. At the moment, it breaks Chocolatey's versioning:

output from cver all -lo

7zip              9.22.01.20120225
7zip.install      9.22.0
ccleaner          3.23.1823
ChocolateyGUI     0.0.5
nodejs.install    0.8.17
vcredist2008      9.0.30729.1
vcredist2010      10.0.40219.1
vvvv              64.29.0
vvvv-addonpack    64.29.0
windirstat        1.1.2.1

The vvvv packages are now listed without their .64 naming, but as version 64.29... I think it would be better to add 'x64' or 'x86' as architecture distinction to those packages. This was also suggested in your cited article. Another solution would probably be to write 'vvvv-64', using the dash or some other unambiguous character to keep it with the package name.

Edited: I misread the original suggestion.

@smakhtin

This comment has been minimized.

Copy link
Owner

commented Jan 21, 2013

The dot divider is currently standard in Chocolatey - just check 7zip package (7zip.install). Looks like Chocolatey interpret after dot part as version if it's not contain any letters. I fixed this issue by changing names of packages to vvvv.x64 and vvvv.x86. Thank you for the tips and contributions.

Comment what you think about this naming and i will close issue.

@smakhtin smakhtin reopened this Jan 21, 2013

@ccoenen

This comment has been minimized.

Copy link
Contributor Author

commented Jan 21, 2013

I think, it's fine now. Thanks!

@smakhtin smakhtin closed this Jan 21, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.