I want to point to a package and have it look to see if there are any packages installed that meet the standards of the package needs.
For instance, I need to see if ruby is installed. I don't care if it is the zipped version or the full blown install.
If it is not installed, then I would like to default to one of these two (the one that doesn't require an install).
Other use cases, install a pdf reader. I wouldn't necessarily care if it is adobe or foxit. I just want one of these to be installed.
See this for more explanation section "3.6 Virtual packages" http://www.debian.org/doc/debian-policy/ch-binary.html
Another resource for explanation: http://www.linuxtopia.org/online_books/linux_system_administration/debian_linux_guides/debian_linux_faq/ch-pkg_basics.en_007.html
This idea should be slightly expanded to include "meta" packages. See https://help.ubuntu.com/community/MetaPackages for an explanation. This would allow packages that don't include anything other than dependencies.
Meta packages are already in chocolatey. Thanks for the suggestion though, I probably need to make the docs highlight that a little more.
From your comment on your blog, I think you're intending to do this in a very different way than Debian does. It sounds like you're intending to have a package that actually points to other packages, which is a bit fragile compared to the Debian way of doing it (a package "Provides" a virtual package, and other packages "Depends" on the virtual package.
Debian is helped out by having a local package list with metadata about all the packages sitting right there, but from what I can tell, Chocolatey will have to query the server. Not that that's a problem, really, but it might be useful to have a list of virtual packages provided by installed packages. Or maybe it's easy enough to parse all the nupkg files to find them on pkg install.
I haven't looked at Chocolatey's inner workings at all, but I want to make sure you've thought about this before you implement it.
Thought about it quite a bit, but maybe I'm missing the boat with virtual packages. I need to depend on the virtual package, but how does the virtual know what packages satisfy the virtual package requirement?
From what you are saying, it sounds like debian uses some metadata about packages to know whether they are say a "PDFReader" or not. That could get pretty server intensive as chocolatey doesn't keep a local list of packages (which also means it doesn't give a nice "Did you mean 'apt-get curl'?" message either.
Perhaps one could depend on a tag, but that's not reliable on the nuget framework. The current method of implementation I've thought of isn't perfect (doesn't automatically have new packages that meet the virtual requirement), but it's a start... :)
"We never usually go the right direction in the start, only discover it after we've made progress."
Although if you have ideas on how to make it easier to register an application as satisfying a virtual requirement, I'm definitely open to it.
I believe in the blog post you were reading, I was thinking of taking virtual packages to a new level where someone could configure whether they want the ".noinstall" or ".install" version of a tool/application (like nodejs). Other packages would only depend on the virtual package and then the one the user wants would be installed.
Any progress? I seriously this feature. Also, have you considered implementing an additional API on your Web site to provide <provides> and <replaces> functionality, if you can't fit it into the NuGet package format?
No progress yet. We have other fundamental design issues to finish back up in the rewrite before we could even approach this. But it will be in a special extension of the nuspec format.
Add API to use SQL Cipher