Apt for Windows

The software distribution model for windows has been:

  1. came on pc
  2. go to store and buy package.  Install from media.
  3. download and install

MANY people cant do #3 but as broadband becomes the norm it will be the dominant form of distribution.  If we can provide apt like functionality NOW then OSS apps will be easier to get and manage than the proprietary alternatives. Perhaps it will lower the barrier to OSS adoption even more.

The Problem:

Locating, Researching, Downloading, and Installing FLOSS software can be difficult in Windows.  Packages such as Firefox are simple because they have static links to all dependencies.  Programs like GIMP use GTK for windows which must be downloaded and installed first.  Dependency resolution has always been difficult but has been addressed on non windows platforms.

The Solution:

Apt is the program used by Debian and derivatives to address dependency resolution as well as locating, researching, and downloading software.  If apt were available for windows programs it could bring the same benefits.

FAQ:

1) What in the heck is wrong with existing windows installers?

The windows install process would remain the same even using apt-win because it works ok (for the windows world anyway).

IT's the software DISTRIBUTION model that I'm advocating to change.  There are some VERY good points about security that need to be addressed but this approach addresses dependency resolution and making it easier to research, locate, and download packages.

Apt and front ends to it would make downloading FOSS windows software MUCH easier and more accessible--something like Xandros networks only for windows.

  1. users can browse/find FOSS software easily
  2. users can downlaod and install with dependency resolution done for them
  3. updates to FOSS software become almost automatic (or actually automatic you you desire).
  4. software is distributed from 'trusted' sources instead of tucows and the virus infected neighbor machine.
2) Wouldn't it be better to use MSI installers?
Probably, but we may not be able to do so for political and technical reasons.  Using the .exe installer as is and wrapping it in another package at least allows this model to work for any windows exe installer.

3)  Is anyone else doing this?
  I found this project and am on the mailing list:  http://www.acm.uiuc.edu/sigwin/wipt.php

Technological Issues

These are discussions from a mailing list I participate in between myself and others:

Actually, APT-DPKG (or APT-RPM) built with MinGW would be
> more worth-while. Anything built under Cygwin _must_ run
> under the Cygwin environment. MinGW, while more involved in
> porting, turns the program into a native Win32 binary without
> the need of a DLL subsystem.
>
> If we're installing native Win32 Freedomware applications, we
> should build native Win32 versions of the front-end (e.g.,
> APT, YUM, etc...) and back-end (e.g., DPKG, RPM, etc...)
> package managers.

I agree. native is preferred.

> But if we repackage them in DPKG (or RPM) and use APT
> (or YUM) as the front-end, then we could at least track
> inter-Freedomware dependencies.
>
> And there could be "wrapper packages" that test the Win32
> system for other, required libraries, etc... That's how
> Rutgers' APT-RPM works for their Solaris roll-outs. They
> built a set of "wrapper RPMs" to translate from Solaris'
> native PKGINFO.

that sounds more like what I was thinking originally. are these
wrappers around the original packages? or wrappers around repackaged
packages?

to minimize work the normal installers would be used instead of
repackaging. the repository and/or the wrapper packages would hold all
of the extra information like dependencies.

> Yes, but _no_ dependency or signature checking in the
> installers. That's the problem.
>
> on the other hand if the apps were repackaged, dependencies would be
> dealt with in the new package.

or maybe the ideal system would support both repackaged and wrapper
packages too?

now that we're talking package management instead of just installing the
question is do we want any of the other features like rpm, dpkg give?
the ability to query for all files in a package etc?

If I were starting this project i would probably forgoe that feature
until later. if it came at no cost i would include it but not
concentrate on it because it is too involved to deal with up
front.  Most other windows programs don't have this
ability either.

What about msi packages? what kinds of 'features' do they support?