If you've been following my articles as of late, you'll notice that I've been exploring (obsessing over) the world of Windows-based package managers. It's an interesting concept that the Linux world gets to enjoy to great success--the ability to download and install applications via a single program, much like how you would grab a song on iTunes or an application off its App Store.
In last week's Murphy's Law, I postulated that this exact combination of one-button glam plus a functional, community-driven application repository would be a surefire way to increase open-source awareness amongst average computer users. That, and it would offer power users a better way to grab, install, and manage large bundles of applications on any number of individual or networked PCs.
A number of you seemed to agree. That's great. But as we all saw in this week's freeware roundup, the state of the package manager market for the Windows operating system is tragic at best. It's difficult, if not impossible, to find a working package manager that fulfills the three main criteria for usefulness: updated applications, minimal downloading errors, and a halfway-decent GUI.
What's the holdup in Windows Package Manager development? Are they really that tricky to create and maintain? And why should users ultimately care about these kinds of applications? To get the answers to these tough questions, I turned to BennyP--creator and sole maintainer of the WinPackMan package manager application. He's currently caught up in bringing this once-popular piece of software back from the dead, making him an ideal candidate for learning more about what's going on in the trenches of third-party Windows package manager development
BennyP: I think it is both cultural and technological. Linux more or less really requires a package manager -- there are lots of libraries and dependency nightmares that really require one. Windows tends not to have these dependencies for whatever reason -- I can install Firefox on a fresh Windows install without having to install anything else. So partly there's a bit less of a necessity.
There are also some technological details that are annoying that have to be overcome -- mostly, the lack of a really good set of standard tools and a powerful scripting language (think BASH and tools like awk and grep, although Windows batch files can be pretty powerful). The Windows registry just adds another layer of complication. There's also the problem of how to deal with software that's already installed -- AppSnap seemed to do this well. The package manager would need to bring these preinstalled programs under its control somehow. You don't really see this much in Linux, so it's kinda new territory. But these challenges aren't impossible to overcome.
BennyP: The biggest advantage of a package manager is the ability to keep programs up to date. Finding applications and initial installations are easier with one, of course. But often, after installing something, I tend not to keep it updated, especially things that don't update themselves.
I have 20 applications or so on my laptop that should be updated, but they work fine as they are. I could be missing out on new features and security patches, but we (myself included) are lazy and aren't going to check 20 or so websites daily or weekly to see if there's an update. Also, if all the software was free and/or open source, it would help people find what they need without going to commercial or ad-based software. A lot of people don't know about the great software out there like Pidgin, or GIMP, or OpenOffice.
BennyP: I came up with the idea after reinstalling Windows once (this was late 2005, I think). I had been playing with Linux for a while and I wondered if there was something similar for Windows, since I had to reinstall a bazillion programs. Surprisingly, there wasn't (although there is one commercial application called VersionTracker. Being a cheapskate, I haven't tried it).
So I started programming, except I'm not a programmer by trade so it was quite a learning experience. The first incarnation was, well, let's forget about that one. The second one (the latest one "available") was ok--it worked, but the code was still pretty rough. Just this last week I starting redoing much of the code after letting everything distill in my mind for a year or two, so we'll see if in a few weeks/months there can be something even better. I expected many people to develop their own, better ones in the meantime. But as you have seen, it really hasn't happened.
BennyP: If you are familiar with Gentoo Linux, ebuilds are more or less my prototype. There are a set of text files (probably zipped/tarred) that the program downloads. Inside these text files are instructions for the package manager on how to install/uninstall/update it. It might be "download this file and run it with some options". But it could certainly be more complicated, especially for programs that don't have installers themselves. The harder parts are uninstalling and updating, but they would be handled much the same way. I think that's the easiest, but most flexible way.
BennyP: The community approach was actually there for me from the beginning. I'm only one man who does this as a hobby, and keeping a large repository of software up-to-date would need a community, particularly if the software developers themselves helped out in maintaining their own entries. But you kinda have to have something to show them first.
BennyP: I think it can be made relatively secure with a few ideas. First, each text file mentioned above contains MD5s (and maybe other checksums) for any file downloaded. Once the file is downloaded, it is checked to make sure everything adds up. This helps with security, but also helps make sure the file wasn't corrupted somehow. There's also the integration of a virus scanner--ClamAV would be easy to implement, but you also have the option to automatically run any user-installed virus scanner on everything downloaded. These take away a lot of the risk, but there will always be some.
BennyP: A package manager is certainly possible under Windows--I had my working very-alpha very-rough version that actually downloaded and managed my few test packages, but the code was a bit substandard. Looking back, I don't know what I was thinking with some of that. Lately I've been moving towards a much more standard C++ code, as well as modifying some things that weren't implemented well. We'll see if it works the third time around.