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)"

13 of 451 comments (clear)

  1. Oh no by Anonymous Coward · · Score: 5, Funny

    C:\>apt-get install bsod

    1. Re:Oh no by Xogede · · Score: 5, Funny

      Error: Package "bsod" already installed.

    2. Re:Oh no by Anonymous Coward · · Score: 5, Funny

      Does this mean we can also do?

      C:\>apt-get remove bsod

    3. Re:Oh no by dhasenan · · Score: 5, Funny

      error: this will break the following dependencies:
          bsod: is required by win-desktop
          bsod: is required by win-gui
          bsod: is required by nt-kernel ...

    4. Re:Oh no by tacgnol · · Score: 5, Informative

      http://windows-get.sourceforge.net/ Maybe we can google these things?

  2. It's the package selection process by zedman · · Score: 5, Insightful

    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.

    1. Re:It's the package selection process by maxwell+demon · · Score: 5, Insightful

      If the explicit goal of an application programmer was to move people to Linux, the ideal strategy would probably be as follows:

      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).

      --
      The Tao of math: The numbers you can count are not the real numbers.
    2. Re:It's the package selection process by PinkyDead · · Score: 5, Funny

      Sorry to burst your bubble, but I think Microsoft has already patented your process.

      --
      Genesis 1:32 And God typed :wq!
    3. Re:It's the package selection process by Anonymous Coward · · Score: 5, Insightful

      why do we have to push Linux on people? I'm a massive Linux fan, but I use windows as my main desktop mainly due to games but I use a lot of open source tools on my windows machine. main two being audacity and Firefox and if I was forced to use linux as my main desktop because I couldn't get these apps on windows frankly would annoy me as much as Microsoft does with there windows only programs.

      That type of mentally will do more damage to the open source movement then anything else.

    4. Re:It's the package selection process by TheRaven64 · · Score: 5, Informative
      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.

      --
      I am TheRaven on Soylent News
    5. Re:It's the package selection process by westlake · · Score: 5, Insightful
      Windows' shaky foundations constitute the main incentive for Windows users to make the switch

      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.

  3. There may be an existing solution ... by baileydau · · Score: 5, Informative

    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 ... and forget to start again?
  4. Not sure by Mostly+a+lurker · · Score: 5, Interesting
    Superficially, this seems an interesting project. I think, though, the problems with managing open source software on Windows are going to be very different to those on Linux: possibly to the point where what you can achieve will be limited.

    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!