Slashdot Mirror
A Windows-Based Packaging Mechanism
FishWithAHammer writes "As part of my Google Summer of Code project, I'm working with WinLibre to develop a Debian-like software download system for free/open source software on the Windows platform. My reasoning is that open source software suffers from poor presentation. Most computer laymen, even those aware of open source software, often don't have any idea how to go about looking for it, but would use it if it were easier to access. What I have proposed is both a Debian-style packaging mechanism (capable of using Windows Installer MSIs or not, as the user wishes) and a software 'catalog' that takes the best aspects of Synaptic and Linspire's Click-N-Run system. Seamless, simple installation and removal of programs in as straightforward a way as apt-get (there will be a command-line tool as well). I'm posting to Slashdot to get the ideas of you lot who, while you may not be the target audience, can certainly provide insights that can be of value." Read on for more of this reader's ideas and questions.
There are areas that I'm personally not familiar with, and while I have done some research I would like the opinions of Slashdotters on some others. While at first I intend to set it up so that WinLibre (and I) run only one repository, I am curious as to how this sort of tool could be most useful to network administrators. Customizable repositories will be available; the code will be under the GPL, after all, so it'd be a little hard for them not to be available.
I'm also interested in the ideas of those who might be in a position to roll together packages. I intend to package a number of open-source language interpreters with the core software to allow special pre- and post-install scripts, as well as removal scripts. C#Script, Perl, and Python are definites, as is a Cygwin sh interpreter. We will have some program requirements — chief among them that no registry changes may be made by the program — but some of them, I fear, will require some flexibility; some programs really do require a way to edit the registry, for example, and I am considering offering some sort of tracked way to make registry changes so they can be rolled back on uninstallation of the program.
I'd love to hear what Slashdotters think of this. Think of it as a wishlist, but you don't get any damn ponies.
Ed Ropple (FishWithAHammer)"
There are areas that I'm personally not familiar with, and while I have done some research I would like the opinions of Slashdotters on some others. While at first I intend to set it up so that WinLibre (and I) run only one repository, I am curious as to how this sort of tool could be most useful to network administrators. Customizable repositories will be available; the code will be under the GPL, after all, so it'd be a little hard for them not to be available.
I'm also interested in the ideas of those who might be in a position to roll together packages. I intend to package a number of open-source language interpreters with the core software to allow special pre- and post-install scripts, as well as removal scripts. C#Script, Perl, and Python are definites, as is a Cygwin sh interpreter. We will have some program requirements — chief among them that no registry changes may be made by the program — but some of them, I fear, will require some flexibility; some programs really do require a way to edit the registry, for example, and I am considering offering some sort of tracked way to make registry changes so they can be rolled back on uninstallation of the program.
I'd love to hear what Slashdotters think of this. Think of it as a wishlist, but you don't get any damn ponies.
Ed Ropple (FishWithAHammer)"
C:\>apt-get install bsod
That's great of course, but it's the community and a selection of packages with mutually consistent packaging metadata which make systems like Debian and their derivatives so popular. The packaging system itself is an enabling technology.
Do not let this become a new attack vector.
--- These are not words: wierd, genious, rediculous
interesting but for it to be popular on window IT HAS TO HAVE a user friendly interface not just a command line tool (btw look into new powershell for windows ;) )
I would say the big thing that I would look for in such a product would be a consistent (or even better, non-existent) use/removal of registry entries. I have dealt with so many so-called "professionally" done software pieces that upon uninstallation would leave several dozen registry entries. This seems terribly unnecessary, and if the so-called apt-get method could circumvent the registry (much like the run from USB flash drive programs) altogether, or at least make it a sure-fire thing to remove, instead of wipe-and-pray.
Good on you for trying to better the system man, I wish you the best of luck!
For user-specified (or multiple fallback) repositories, you need nothing more complex than reading your base path(s) from a config file. Prepend that address to every file you download, and it will all go well.
For the bigger project, basically you just need a set of per-package install/uninstall scripts that check for dependancies (or no-longer-needed dependancies on uninstall), do their thing, and write themselves to a standardized catalog of installed software. Whether or not you can adapt Windows' list of such software, and the MSI interface in general, to your needs, I can't say offhand. I would think you can at least list the package therein, but I don't think that handles dependancy information quite as elegantly as you would want.
I see the biggest problem you'll have as coming from the poor regression testing done for Windows ports of FOSS - You may well need multiple (version-specific) instances of some dependancies installed at the same time, for different packages that use "working until version 2.8.10.4" features (or more of a nightmare, "working until KB935356").
Overall, I wish you luck with this. I think the Windows world has needed something like apt-get (with a mind-numbingly simple GUI) for a loooooong time.
That packages provide functionality. This is already done in the form of virtual packages like web-browser, but I'd like to go further.
.pcx file, and have no clue what is it, what can I open it with?
.s3m files?
.s3m files) and "fully implements" (can create .s3m files).
For example, the current system is that OO Writer and KWord are in the "word processor" category. But what if I want something that can open AmiPro documents? What options do I have there? That's generally not included anywhere in the package's description.
I found this weird
Or, what music player has the ability of playing
What mail clients can I choose from if I'd like both NNTP and IMAP support?
What programs are available that do some function that is related to an HP nx5000 laptop? (this would match programs controlling LCD brightness, support for the onboard bluetooth, etc)
A nice thing would having these capabilities roughly grouped as "can access" (can play
Accepted does not mean decent.
Add/Remove really doesn't have anything to actually Add. And the Remove aspect of Add/Remove doesn't actually remove. Some programs go so far as to only remove the shortcuts and say "Uninstall Complete!", while others leave behind large swaths of registry entries and several MB of unnecessary files at C:\, Windows, Program Files, AppData, Local Data, Local Data\AppData (the other AppData, ugh) and anywhere else they please.
But the real failure in Windows is a decent way to keep any number of applications up to date. This would be a fantastic reason to use FOSS in Windows, because for all there would (hopefully) be a central, trusted and easy update system for all FOSS on your Windows machines.
You have been eaten by a Hurd of GNU.
There is a mechanism for doing this kind of thing already in Windows, via Add/Remove programs and Group Policy. Surely it would be a good idea to try and re-use this rather than re-inventing the wheel.
No, it would be a wonderful thing, although I don't think it'll fly.
On Windows one of the most annoying things that that things install themselves -- which gives them full control over what goes where, up to modifying obscure registry settings and overwriting files. That means you can never be sure you can uninstall something.
Package managers solve that: When I install say, kword it doesn't install itself. The package manager knows exactly what went where and can remove it. KWord itself runs as a normal user account and doesn't have the privileges required to make itself not removable.
But for working well this sort of thing needs everything to be packaged, and I doubt that'll ever happen except in a very few controlled environments.
So, in theory this should work with ReactOS when they are both finished, right?
I hope you're planning on making it interoperate with the cygwin packaging system. Cygwin's a great piece of software which is, IMO, let down by its obscure and difficult-to-use setup program. A new, friendlier way of installing and updating cygwin components would be a great asset. And if it worked with other OSS stuff as well, that would be a huge asset.
.exe that doesn't require your system, but which can interoperate with your system easily -- perhaps by having a version of your system that can wrap up a package with a copy of the relevant parts of itself in a .exe file.
One thing I would suggest is that you make it easy for somebody to package a standalone
It is not only the programmers' fault, though. Far too few users bother to suggest interface simplification,or even know how to advocate it. Merely complaining will not work - developers need to be shown that it can be done, and how, by means of mock-ups or illustrations. A few innovative user interface interested users could do wonders for many projects simply by drawing new user interfaces and submitting them to various free software projects, asking if they are interested in going a few rounds of design iterations with them. Often an outside eye, and interest in doing some adapting from both sides, is all that is needed.
You may want to look at wpkg (http://wpkg.org/)
It is a windows package management system based on dpkg.
We use it at work and it appears to work fairly well. Although I don't know for sure, as I'm not the PC admin and I don't run a Windows desktop :)
I just get to hear him saying how much easier it is to manage the PCs with it.
Ever stop to think
They all handle updates as well, so you have a central place to keep all your entire system patched. For example, when a vulnerability is discovered in a core library (libz, or linpng have been recent examples), you need to go through your system checkiing that every application which uses one of these libraries is updated. This is almost impossible on Windows, but automatic on systems with package managers.
The first issue that occurs to me immediately is that Windows has no single suitable native package management system that you can hook onto. Because of this, program installations tend either to (i) include whatever prerequisites they need and check whether their installation is necessary; or (ii) list the prerequisites in the installation instructions and leave it up to the user to ensure they are satisfied. Now, you might say that the whole point of the project is to resolve this, but I think you are going to run into licensing problems when you try. Let's say a particular open source product relies on .NET Framework 2. Are you then going to include .NET Framework 2 in your repository? Are you going to download it from Microsoft, using Microsoft's Download Center as a kind of adjunct repository? Are you going to talk to Microsoft to see if they will cooperate in working out a solution? This seems hard.
I do think that a single starting point for finding quality open source solutions on Windows has merit. Right now there is a bewildering mass of products out there, and no easy way of sifting the gems from the dross. If nothing else, you might be able to provide a good menu of open source products that are deemed worthy of consideration.
Good luck!
Microsoft already has an open packaging format for installers, it's called Windows Installer (formerly Microsoft Installer), or MSI for short. MSI 3.1 supports Windows 2000+. http://msdn2.microsoft.com/en-us/library/aa372866. aspx
Why re-invent the wheel? This is open to everyone and well documented on MSDN and countless forums all over the web.
One thing I think shopuld be considered from the beginning is how to handle multiple archives, which may be independently maintained. Sure, the basic operation is simple: You add a new URL to the list of archives to search, and then you can see the contents of those archives. However that's not all there is to archives:
1. How do you find additional repositories?
2. How do you find out if a given repository is trustworthy?
3. What to do if several repositories contain packages for the same application or library?
4. What about version inconsistencies?
Points 1 and 2 can IMHO be (mostly) solved together through a "repository web": Repositories not only contain packages, but also links to other repositories. Those links should also be rated, so you get a web of trust for repositories: You can mark several "root repositories" as trusted or untrusted (those settings should, of course, be user-changeable). Then trust would "propagate" through links marked as trusted, or "anti-propagate" through mistrust-links. One could even imagine "repository hubs", repositories which don't contain files, but only links to other repositories together with trust ratings. It might also be a good idea to have several trust ratings for the contained files, and for the contained links (after all, you can well imagine an excellent file repository where the maintainer isn't able to accurately rank the trust on inter-repository links).
For points 3 and 4 I don't have a suggestion right now, but they definitely should be considered (note that separately maintained repositories will almost certainly cause inconsistencies at some point).
Of course you can just pretend that there will always be only one repository, or that all repository providers will work together to avoid inconsistencies, but I think that's not really a good idea. Additional independent repositories will eventually come (assuming the project is a success), and therefore the problems caused by those should definitively be anticipated, even if originally there's only one repository.
The Tao of math: The numbers you can count are not the real numbers.
It's a stealth feature. Get people installing applications that way, because then the Linux desktop will be more familiar.
Something really is needed. I keep coming across people who really need no more than Wordpad who are buying Office because they think they have to. I recently came across a guy who has bought Office 2007 and writes nothing but letters and the odd email. He thought that somehow saving his letter to Auntie Flo in Office 2007 format (docx) was "better" than saving it in Office 2000 .doc, right up to the point she couldn't open it as an email attachment and he had to "downgrade" his document. Microsoft is exploiting numskulls like that. (I'm only jealous of course - I'd love a list of 100 or so gullible people with money but, as I'm not a corporation with deep pockets, I might get into trouble.)
These people don't know OOo exists, and even if they did would never be able to find it. But a simple little packager that has a "Top picks" with something like "Open Office 2 - for all your home office needs" and a "click here to install" button - well, at least we'd be trying.
Pining for the fjords
This is one of the areas where Free Software is far, far ahead of what Windows currently has.
Right up until the software you want isn't in the repo, or is broken. Then it falls way, way behind.
There's also the "what the hell is it called" issue, but that's become less significant in the last year or two, although that benefit is largely restricted to Ubuntu and its derivatives.
An apt-get equivalent for windows would be a very cool thing, I hope you succeed.
You might want to reconsider the decision not to use MSI as a back-end. I am not familiar with the details of the technology, but some of the supported features are command-line and GUI installs, and administrative network installs. And if you don't already know, Microsoft has released some open-source (!) tools for generating MSI packages: http://wix.sourceforge.net/
I have been thinking about this recently.
I have lots of applications, both OSS and commercial, that have some kind of update system built in - the application checks for an update when you start it, for instance, or when you select the option from the help menu. In fact it is getting to the stage where practically every app. has this.
What I would like to see is a single open method of doing this which could work for all applications (so even commercial software providers could opt into it if they wanted), which would be simple and secure. It would be great to have a single application open that ran at start-up that said: "The following applications have updates available:" and then lists the applications, and two buttons "Update all" and "Advanced" which would allow you to see details about the updates and select just the ones you want.
For instance on my Mac I have:
1) The Official Apple "Software update" that updates OSX and Apple Apps.
2) The Adobe updater for Photoshop, Dreamweaver etc.
3) The Firefox/Thunderbird updater
4) Dozens of updaters for individual apps like TextMate and OSS software
5) Updaters for OSS packages (Fink/darwinports)
(Yes, I know about the App Update widget but that only addresses part of the problem, and it does not provide a technical solution that can be used across platforms and projects).
And on Windows, I have the same kind of mess of updaters.
I'm sure there could be a simple, elegant technical solution for this, a kind of RSS-type standard for application updates - you could then choose your prefered updater just as you can now choose your preferred RSS reader.
C:\> apt-get remove iexplore
(full disclosure - my brother made/runs/writes the windows package manager (http://www.winpackman.org)) - It is tough, and slow, especially when attempting to do it right (not a criticism of anyone), but windows installers tend to throw crap everywhere, especially into the far reaches of the registry. That is one of the goals of the winpackman, to organize the files a little better and provide an undelete function. That being said, Winpackman is still pretty early in development, after some problems with GTK and some messy installers, there has been a total rewrite (the first version had a HORRIBLE GUI). Btw - not to jump on the "criticize Slashdot bandwagon", but about 6 months or so ago I submitted an eerily similar story about our Winpackman. I'm not mad at slashdot, it's just kinda creepy. haha
Your complaint boils down to "some people make bad packages", which occurs on Linux as well, and is just the nature of software to be imperfect. I cannot count the number of bugs or non-working setups I've tracked down to bad packages, and even better, in the Linux world fixing such a bug once doesn't make it go away - it'll be repeated in 3 months time by a different distribution.
That would be nice, yes.
In reality, it tends to work the other way around. Take the Amiga emulator, UAE, for instance. I think, among other meanings, the U once stood for Unix. Yet, most of the best features are in the Windows version now, and they're developed in a non-cross-platform manner, by people who don't care about OpenGL's standardisation over DirectX, etc. Same with other emulators, and probably lots of other tools.
Unfortunately, Free Software is a victim of its own generosity, when parts of it are ported to windows. Especially given that the initial ports tend to be half-hearted, and half-working compared to the Unix versions, so that people think Free Software sucks, until it's had a while to become windows-ized through its that community.
STILL... it seems obvious to me that something like a usuable, popular, apt for windows could literally beat microsoft's monopoly. When you can browse to the office section of your package manager, and you're immediately presented with a choice (Install OpenOffice now, and lots of extra, compatible software) or run install the wrapper package for Microsoft Office, after buying the CD, proving you didn't steal it with a 98-digit code, etc.)... well, it would really level the playing field.
I actually thought this was the point of Google Pack -- to beat microsoft by taking over and opening up the distribution channel. It's a shame (no, literally, a SHAME) that they didn't do a better job on that, by making apt for windows then. I'd be glad to see a real APT for windows. Unfortunately, I'm not sure it's possible, without the mass of a debian-like project behind it, a very easy and presentable UI, and open, usable APIs that encourage developers to use it. Hint: it has to work as well as apt, but not be half as hard to make packages for. Good luck, I say.
Dude, one time, I did that... registry exploded...
word of honor.
Please stop stalking me, bro.
These projects truly are a testament to the true flexibility and power of apt-get, even within a Windows context. Side efforts, such as an ncurses based implementation of Mac OS X's Expose feature for dealing with multiple apt-get sessions, a SIMD/MMX accelerated apt-get, interplanetary control software with apt-get, and last but not least, a dselect-based implementation of iTunes.
While I applaud the efforts of those seeking to bring a more GNU/Linux-like package management experience to Windows, we should not forget the efforts of the early pioneers.
Linux will gain market share over Windows by being better than Windows. My experience with open source came through open source applications on Windows. I use those applications because they are superior, not because they are free. I think those apps will work even better if I replace Windows with Linux. So think of open source apps on Windows as a gateway drug to Linux (or *BSD).
I think it'd be nice if such a system had a "similar to:" feature. For example, lets say Joe User has the package manager installed. He goes to it and looks for "Photoshop". Well, he's not going to find Photoshop, but if setup properly he would instead find "GIMP".
This space for rent.
And will go further to say that Firefox and OOo have enjoyed this level of success (from Windows) BECAUSE users didn't have to wrestle with a bloody package-manager to get the software installed. Windows and Mac users always get the earliest access to the latest FOSS updates, while Linux users must wait for their repository to catch-up or learn how to fight with the package manager.
In fact, Mozilla is so fed up with *nix package managers and umpteen different repositories, that they no longer even distribute their Linux binaries in RPM nor will they self-update.
Repository "priests" insert themselves between the end-user and the application developer, making things more complicated in the end for everyone except the thin-client sysadmins.
The respository/package manager paradigm cuts across the grain of personal computing culture. Very few Mac or Windows users would put up with what amounts to thin-client management methods for long. Note that ports and fink have been available for the Mac for some time, and only a sliver of the Mac techies ever use them.