A Windows-Based Packaging Mechanism 451
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)"
Security, security, security. (Score:4, Interesting)
Here's a concept I'd like to see (Score:4, Interesting)
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
Re:Registry (Score:3, Interesting)
Something I've always missed it the --purge feature, sometimes you want to do a re-install without losing your configuration and sometimes you simply want to get rid of it all.
Re:It's the package selection process (Score:3, Interesting)
The desktop I use at work is a Windows one, as this is what all but one customers use -- so even though I spend a lot of time sshed to a real box, things like Firefox, Gimp, TortoiseSVN, etc, etc, are all win32 binaries. And having them keep up to date by a single command as opposed to visiting every single homepage once in a time would be swell.
Re:Registry (Score:2, Interesting)
Avoiding registry settings is very difficult if the applications are coded to store their settings in the registry. Most people do not realise however that you can move COM registration (ie HKCR/CLSID, HKCR/Interfaces, HKCR/TypeLib etc) out of the registry and into manifest files on XP/W2k3/Vista.
I would suggest that you either:
(i) recode applications to make them trivial - ie all the applications files self contained in a single folder (OS X style). User preferences obviously should be separated.
(ii) create a registry redirector that redirects certain registry calls into files (Altiris SVS style)
(iii) still with Windows Installer packages (generated with WiX)
Re:Really? (Score:2, Interesting)
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.
Re:Utterly Pointless (Score:3, Interesting)
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.
ReactOS compatibility (Score:3, Interesting)
Re:Registry (Score:2, Interesting)
It's hardly a new idea; in the past I'd toyed with trying to start a grassroots movement I called Windindin (Windows Data Independence Initiative), that would push for Win32 developers to adopt standards that would deprecate use of the Registry and place config and state data and even user files in predictable standardized places, to make them easy to find AND easy to collectively back-up.
Sounds great, right? Not gonna happen, for a couple reasons: the de facto standards-setting ability of Microsoft and its overwhelming influence with commercial developers, and because the ONLY group it would truly benefit is consumers, the user. Where's the economic incentive if consumers don't even know they need this, much less come to the point of beating down doors demanding it?
The reason the Registry gained traction is because (a) Microsoft is the 800-pound OS gorilla and (b) it actually benefits software developers. The gorilla is still alive and kicking, and commercial software CxOs and project managers are greedy lazy bastards who won't do the right thing if it happens to make their job more difficult.
Not sure (Score:5, Interesting)
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!
Considerations about multiple repositories (Score:4, Interesting)
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.
Updates system for OSS (Score:5, Interesting)
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.
Re:Cygwin packaging (Score:3, Interesting)
Cywin's setup.exe is a PIA, but hardly unfriendly. It behaves in much the same way as most GUI programs. Short of writing a "wizard", I don't see how it could it made more friendly. Where the setup.exe approach fails is that on the front end, it's not command-line driven, and the backend, well, there really isn't one. My guess is the developers are already working hard as it is, and expecting such an oft-discussed overhaul any time soon is unreasonable.
As for
I think that's an admirable goal, but what's being proposed? ActiveState distributions? And what all those GNU utilities? Is he proposing native versions of some tiny subset of what everone takes for granted? The core utilities, along with interpreters like Perl, Python, etc. etc., etc. are already included in Cygwin. Just as importantly, you get the benefit of Unix file formats, Unix-style paths, symlinks, shells, and a fairly nifty terminal that together go a hell of a long way to present a sane (and coherent) environment so that you can make use of them.
I do think the article poster is onto something, but I don't think he'll get much farther than providing a small collection of popular programs for Windows users who either don't know any different, or for whom installing something like putty satisfies their needs. Not bad in and of itself, of course. But for everyone else, we'll have to wait for what I hope is the inevitability that Windows will evolve to resemble Unix systems.
Re:It's the package selection process (Score:4, Interesting)
Like someone said up in the thread, there is no way to prevent anyone porting nice OSS app to non-free OS. Therefore, users will virtually never feel the urge to switch over to Linux because of a "killer app(s)".
When (or if) massive switchover happens, it will be only because Microsoft tried to squeeze users too much and they found they lose nothing important if they switch.
In other words, blurring the border between the two by porting Free Software on proprietary platforms, making users gradually adapt to environment they would find in Linux, makes user migration to it more probable, in fact as probable as realistically possible. Side effect would be pushing the shareware producers out of the Windows market by pressure of irresistible competition, which in turn would decrease number of developers for that platform and at the same time force Microsoft to "deal with devil" and try to play nicer with FOSS side and users.
Re:There may be an existing solution ... (Score:3, Interesting)
It's a brilliant first go at it, though.
Re:It's the package selection process (Score:1, Interesting)
this is only further proof that the oss 'movement' has nothing to do with better computing standards but rather is a matter of people who are too cheap to buy software.
so while you linux fanatics are crying yourselves to sleep tonight for not being on the winning team just remember that copying the other teams game book probably won't benefit you either.
thanks for showing your true colors.
Re:It's the package selection process (Score:3, Interesting)
The cutting-edge iMacs that they got in during my 8th grade year were probably the worst advertising Apple could have hoped for. I'd bet that everyone who went through that school now has a strong bias against Macs.
They crashed way, way more often than win98 (not just the ones that were in computer labs being screwed around on by a few hundred students, I mean just-out-of-the-box ones issued to teachers) and performed like 2-3 year old (at the time) PC hardware. Add to that the fact that they were way, WAY more expensive than comparable PCs then (Apple's worked on this a bit; it was REALLY bad back then) and I doubt anyone there had a positive opinion of the things.
Macs definitely did not always win in the reliability category. That's a fairly recent development, in fact.
"Similar to..." (Score:2, Interesting)
I agree (Score:3, Interesting)
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.
Re:MSI (Score:4, Interesting)
But MSI doesn't do what the Linux/BSD packagers do. These packagers work by tracking every single file or update done to the entire system. Then they track dependencies between files and packages. They store all this in a database format, which allows you to ask questions like "what is every package that uses MSVCRT71.DLL? And "what will break if I update package GIF_VIEWER from version 1.0 to version 1.1?" They also manage side-by-side installs, provide a central repository for searching for packages and upgrades, and provide a safe digitally signed repository for applications.
This is one of the killer features of Linux that I miss on Windows. But I suspect it won't work for the same reasons it doesn't work on Linux. It's only useful if 100% of the applications use it. If any one of them doesn't, then the whole system can come crumbling down. But basically, it is a fix to DLL hell, so it can't make things on Windows any worse.
On a note of MSI, MSI may seem to do the above, but it doesn't. It's a packaging format, and it allows for install and rollback much like the Linux packaging systems do. But most of the time it is unrealistic to expect the repair/rollback/uninstall features to actually work. I've worked at a few companies who have made MSIs, and generally you take some other EXE or script-based installer, then you wrap it in an MSI and say you are done. You rarely use the actual MSI features because they are too complicated and the tools don't generall support them. And Windows installs are full of kluges like editing a registry key here, adding a shell extension there, etc. Things generally don't fit into the nicely packaged mentality.