Fortunately the other 95% has been solved several times over: dpkg, RPM, pacman, etc. Why bother writing another package manager for OSX? I'm puzzled.
MacPorts can actually generate dpkg, rpm, and even Installer.app packages, but there hasn't been the resources or interest in maintaining a tree of binary packages. There has also been work into creating a dpkg-alternative via xar.
Fink produces dpkg packages as well, but has resource constraints in producing up-to-date trees of binaries.
I think there is a modest but extremely unglamorous business opportunity here ...
Definitely allowed, but could you prevent users from simply copying your packages to an open repository (ala CentOS vs RedHat)?
MacPorts can actually generate dpkg, rpm, and even Installer.app packages, but there hasn't been the resources or interest in maintaining a tree of binary packages. There has also been work into creating a dpkg-alternative via xar.
Fink produces dpkg packages as well, but has resource constraints in producing up-to-date trees of binaries.
I think there is a modest but extremely unglamorous business opportunity here ...
Definitely allowed, but could you prevent users from simply copying your packages to an open repository (ala CentOS vs RedHat)?