macos.eclass provides the functions to unpack a dmg, and install a .app. macos-bin.eclass sets up defaults for installing a binary .app from a dmg. Included are two ebuilds that use macos-bin.eclass. With these eclasses, portage can be used for managing normal desktop applications on OS X, something that no other package manager currently does. There are two current issues: 1. A few .app's have broken symlinks, so far I know of Adium and VLC. In both situations, the .app works with the broken links removed, and I have filed a bug report for both .app's. If you're packaging a .app, keep this in mind. 2. .apps can't be removed properly after you run them for the first time. Portage doesn't seem to want to remove the .app/Contents/Frameworks/*.framework/Versions folders, although they appear empty. This should be resolved before adding to portage, but I can't find a reason why portage won't remove the empty directory. Once #2 is resolved, we could actually add support for ppc-macos to mozilla-firefox-bin, mozilla-thunderbird-bin, and similar packages.
Created attachment 62348 [details] macos.eclass
Created attachment 62349 [details] macos-bin.eclass
Created attachment 62351 [details] abiword-bin-2.2.8.ebuild Ebuild to install binary abiword
Created attachment 62353 [details] adium-bin-0.82.ebuild Installs binary adium
This idea is pretty cool! However, it remains a question whether real OSX applications should be mixed with Unix/Linux applications. For OSX applications, Apple made it easy to use them, even move them to other locations without a penalty, even when the application is running, etc. It is a concept to the user to drag the icon from the dmg to his/her Application folder and drag it to the Trash when he/she wants to get rid of this. Also, applications like Adium check themselves for newer versions and want to upgrade when they detect so, most probably before portage marks them stable. These few examples show portage and the real situation on disk can get out of sync easily. I could imagine portage being your friend with "emerge -s" when looking for certain functionality/packages. Whether this is any better than a google query remains the question both speed and result wise.
While the default package management system on OS X is amazing compared to you know what, I, personally, have been spoiled by gentoo. Having to go to websites to install a program, and having to update all programs individually seems backwords to me after using gentoo :). There are two things which, if they are done, I believe can make this a successful system: 1. Keep the ebuilds up-to-date 2. stabilize the ebuilds much more quickly than normal, i.e. after a few days or a week at most Keeping the ebuilds up-to-date should be easier than in normal portage, becuase the packages are binary, and you should just be able to change the version number of the ebuild and have it Just Work (tm) with much more success than the standard compiled package. As for self-updating programs, the user will (hopefully) know that the program is managed by portage, and how to update it using portage. I don't think an application popping up a message box saying there is an updated version is a problem, gaim does the same thing as adium.
I believe you have a strong point that a user who uses OSX portage, should know what he/she is doing, so it would leave updates and location up to portage at any time. It would be great to be able to do "emerge camino-nightly-bin" which would update my binary every day. Impossible to create an ebuild for every day though.
A really cool idea! I think that an unser who install portage on OSX can remeber what package are installed and update this with emerge.
This needs hashing out the portage aspect. Also, it is questionable if binary variants should be used (.dmg) instead of the sources. Some projects already build .apps which we install.
