Ryan Schmidt wrote: >> there's one more point here, which is that this is only really an issue when >> the build time is long. If macports does eventually have binary installs, >> then the problem also goes away as the build time should be a lot quicker >> anyway. > > Right, I forgot I was going to mention that point as well. MacPorts *does* > have binary installs, as of MacPorts 2. Not all ports are built as binary > packages yet, nor for all operating systems and processor architectures, but > hopefully the number of available packages will increase as we sort out > issues over the coming months.
Those should probably be called binary "archives", since there is no package manager available that will install them ? At least that is the terminology used in the Guide, where "packages" refers either to the Installer.app's .pkg or to the (external) RPM's .rpm. It's rather confusing, especially to the casual user who couldn't careless - "prebuilt". I'm thinking that the support for .pkg and .rpm should both be removed... Then there's only one type of package, even if one needs to redo "base" and the MacPorts port. On the plus side, then one could use a unified installer for all OS versions instead of three ? And get rid of the obsolete .dmg wrapper, while dropping support for the unsupported Tiger... --anders _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
