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)"
Oh no (Score:5, Funny)
Re:Oh no (Score:5, Funny)
Re:It's the package selection process (Score:2, Funny)
just kidding. ..
Re:MSI (Score:2, Funny)
Re:It's the package selection process (Score:5, Funny)
Re:Oh no (Score:5, Funny)
C:\>apt-get remove bsod
Re:Oh no (Score:5, Funny)
bsod: is required by win-desktop
bsod: is required by win-gui
bsod: is required by nt-kernel
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?
true story (Score:3, Funny)
Dude, one time, I did that... registry exploded...
word of honor.
Re:Oh no (Score:3, Funny)
Yes! YES!!
Windows apt-get was developed years ago (Score:2, Funny)
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 [slashdot.org] feature for dealing with multiple apt-get sessions, a SIMD/MMX accelerated apt-get [slashdot.org], interplanetary control software with apt-get [slashdot.org], and last but not least, a dselect-based implementation of iTunes [slashdot.org].
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.
Re:Oh no (Score:2, Funny)
> Windows Operating System
> Explorer.exe
> Continue Y/N?
You got it all wrong. It should be like this:
C:\> Removal of BSOD requires the following dependencies to be uninstalled:
> Windows Operating System
> Explorer.exe
1. Cancel
2. Allow
Re:Oh no (Score:1, Funny)