Slashdot Log In
A Windows-Based Packaging Mechanism
Posted by
kdawson
on Tue May 29, 2007 05:09 AM
from the simple-install-and-remove dept.
from the simple-install-and-remove dept.
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)"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Oh no (Score:5, Funny)
Re:Oh no (Score:5, Funny)
Parent
Re:Oh no (Score:5, Funny)
C:\>apt-get remove bsod
Parent
Re:Oh no (Score:5, Funny)
bsod: is required by win-desktop
bsod: is required by win-gui
bsod: is required by nt-kernel
Parent
Re:Oh no (Score:5, Funny)
C:\> Removal of BSOD requires the following dependencies to be uninstalled:
> Windows Operating System
> Explorer.exe
> Continue Y/N?
Parent
Re:Oh no (Score:5, Informative)
Parent
It's the package selection process (Score:5, Insightful)
Re:It's the package selection process (Score:5, Insightful)
If GNU/Linux was the only operating system that had applications like Firefox, OpenOffice, VLC, and so on, I think it would be a much more attractive option than Windows is. Yet, we've ported some of our best applications to the proprietary Windows platform, and as a consequence of this there is less incentive for Windows users to become users of Free Software operating systems.
I'm not necessarily saying that these ports shouldn't take place, but I think we should be aware of the fact that porting a great application to Windows does lessen the incentive for Windows users to make the switch.
Parent
Re:It's the package selection process (Score:5, Insightful)
1. Port the application to Windows
2. Get people addicted to it (that's the hardest part).
3. Make sure that new developments are always available on Linux first (so that there's a real incentive to switch to Linux).
4. At some time, introduce Linux-only features.
5. After enough users have switched to Linux, drop Windows support.
6. ???
7. Profit!
(Sorry, the last two lines just had to come!
Of course the problem with this plan is that starting from step 4 on, it's virtually impossible to do with FOSS: If you don't implement those features on Windows, likely someone else will do. And if you drop Windows support, probably someone else will take over (remember, as of step 2, it's a popular application).
Parent
Re:It's the package selection process (Score:5, Funny)
Parent
Re:It's the package selection process (Score:5, Insightful)
That type of mentally will do more damage to the open source movement then anything else.
Parent
Re:It's the package selection process (Score:5, Insightful)
Actually, this brings up a very good point. For some applications like Audacity, the preferred platform may actually be Linux, or more specifically, distros that are aimed at being a professional audio/video workstation like Ubuntu Studio, which includes a low-latency kernel tuned for A/V work and dozens of audio tools that are only available on *nix. Audacity may work on Windows, but I've used it on both platforms and I much prefer to work with it on a low-latency-optimized Linux setup, right beside applications like Ardour with a plugin architecture like JACK.
Parent
Re:It's the package selection process (Score:5, Insightful)
Parent
Re:It's the package selection process (Score:5, Insightful)
"We've ported to Windows"? Who the heck are ya?
Firefox, based on the XUL platform, which from the very beginning was designed to be multi-platform.
It has evolved from the proprietary Netscape before were also inherently multi-platform from the very start.
OpenOffice, evolved from the proprietary StarOffice, inherently multiplatform.
As for VLC, why exactly not having this one on Windows makes Linux any better. Can't Windows play Windows Media files? Does it lack a hundred of other players?
And I have another question for you: who do you think make products like Firefox popular. It's Windows users. The majority of people out there run Windows. It's when people started installing Firefox on their Windows machines, that the stats went up, and Firefox started to matter.
If Firefox never existed on Windows, do you think anyone but geeks would care for it? If you're thinking what answer might be, look no further from Konqueror: who the hell (but geeks) cared about this one browser which was only available on Linux, BEFORE Apple took their code and turned it in WebKit/Safari?
Parent
Re:It's the package selection process (Score:5, Insightful)
The Microsoft platform can't be that shaky if Apple hasn't been able to get and hold 10% of the market in damn near twenty-five years.
Parent
Re:It's the package selection process (Score:5, Informative)
The second reason is Windows-specific. On UNIX, you can delete a file that applications have open, and it will not actually be removed from the disk until the last application with an open handle for it exits. On Windows, you can't do this. On *NIX, if you want up upgrade libfoo.so, you can delete it and then install the new libfoo.so, and every running application that uses it will keep using the deleted version until you restart it. On Windows, if you want to upgrade foo.dll, then it will tell you that you can't delete foo.dll because it is in use. This is why Windows installers often tell you to quit all applications. The work-around for this is to add a little script that replaces the old foo.dll with the new one on the next reboot (before anyone has tried loading it) and then continues.
I don't know if the second problem is fixed on Windows - I haven't used it for four or so years - but even if it has there are probably a lot of people out there writing installers who don't know that it's fixed.
Parent
Security, security, security. (Score:4, Interesting)
Re:Security, security, security. (Score:5, Insightful)
Quite a step forward in my book.
Parent
Registry (Score:5, Insightful)
Good on you for trying to better the system man, I wish you the best of luck!
A lot of work, but simple, conceptually... (Score:4, Insightful)
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.
Re:A lot of work, but simple, conceptually... (Score:5, Insightful)
-Actually install MySQL, PHP and Apache easily without having to use a third party package that holds them all. Yeah, windows is sure free of dependencies. Just great especially when your programs are inherently dependent on each other, oh wait no its a pain in the ass.
-Download whatever packages I need without needing to deal with searching the web for the place to download this from. The whole find, download install file, run install file thing gets annoying pretty quickly. Especially when you have a bunch of software to download.
-Queue uninstalls, god damn do I hate the fucking windows uninstaller where you need to uninstall, wait,uninstall next item. Thats not even counting how it fucking breaks in one way or another after a while on most systems I've used.
Parent
Cygwin packaging (Score:5, Insightful)
One thing I would suggest is that you make it easy for somebody to package a standalone
There may be an existing solution ... (Score:5, Informative)
You may want to look at wpkg (http://wpkg.org/ [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.
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!
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.