Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Operating Systems Software Windows IT Technology

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)"
This discussion has been archived. No new comments can be posted.

A Windows-Based Packaging Mechanism

Comments Filter:
  • by baileydau ( 1037622 ) on Tuesday May 29, 2007 @06:06AM (#19306845)

    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.

  • Re:Really? (Score:4, Informative)

    by jcupitt65 ( 68879 ) on Tuesday May 29, 2007 @06:07AM (#19306851)
    apt-get and friends are far, far better than Window's add/remove system. They track dependencies, so when you install "rails", for example, it will automatically install apache, mysql, ruby, all the various connectors, configure them and link them all together. This is especially useful for development. Setting up a complex build environment on Windows can be nightmarish. My project uses 10 - 15 sub-libraries and downloading working and compatible versions of all the dependencies can take a whole day. This is a one-click operation with a package manager.

    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.

  • by funkatron ( 912521 ) on Tuesday May 29, 2007 @06:10AM (#19306883)
    The install-reboot game is easy to get out of. Click no when it asks to reboot and carry on installing stuff, reboot when you've finished.
  • MSI (Score:3, Informative)

    by ericfitz ( 59316 ) on Tuesday May 29, 2007 @06:20AM (#19306929)
    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 [microsoft.com]

    Why re-invent the wheel? This is open to everyone and well documented on MSDN and countless forums all over the web.

  • MSI (Score:2, Informative)

    by the_soulman ( 465347 ) on Tuesday May 29, 2007 @06:55AM (#19307057) Homepage
    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/ [sourceforge.net]
  • by Anonymous Coward on Tuesday May 29, 2007 @07:15AM (#19307165)
    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.

    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.

    See: Zero Install [0install.net]

    And here's the RSS-like feed format [0install.net].

  • Re:feature list (Score:2, Informative)

    by walmartshopper67 ( 943351 ) <jtp0142.rit@edu> on Tuesday May 29, 2007 @07:52AM (#19307371)
    (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
  • Re:MSI (Score:3, Informative)

    by gbjbaanb ( 229885 ) on Tuesday May 29, 2007 @08:55AM (#19307831)
    The OP is not reinventing the wheel WRT an installer, but a way to get those packaged msis to the end-user in a easier-to-use fashion.

    The OP should have a look at Wix (on sourceforge), which was MS's very first foray in to the world of open source. Its a XML-based msi creation tool. It may not help the package manager but will provide the tools for OSS developers to create msi packages (especially if you provide easy-to-modify simple packages) ready to slot into your manager.
  • by TheRaven64 ( 641858 ) on Tuesday May 29, 2007 @09:02AM (#19307889) Journal
    The reboots are required for two reasons. The first is that you are updating a library that a lot of applications use. If you update libc, for example, then you need to restart every C application, which generally means a reboot. In a lot of cases, you can get away with just restarting the affected applications.

    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.

  • Re:Oh no (Score:5, Informative)

    by tacgnol ( 1108669 ) on Tuesday May 29, 2007 @09:13AM (#19307951)
    http://windows-get.sourceforge.net/ [sourceforge.net] Maybe we can google these things?
  • by mrchaotica ( 681592 ) * on Tuesday May 29, 2007 @12:41PM (#19310567)

    You're right: "open source" can mean using Linux, Solaris, BSD, or even HURD. However, it does also mean "not Windows!"

  • Re:MSI (Score:3, Informative)

    by julesh ( 229690 ) on Tuesday May 29, 2007 @03:45PM (#19313103)
    Because MSI doesn't support automatic dependency resolution, would be the major reason. A simple wrapper around MSI would be the ideal way of achieving this goal, but MSI alone doesn't provide the kind of feature set we've grown used to in the Linux world.

The one day you'd sell your soul for something, souls are a glut.

Working...