macports fetch suggestion

[Ryan Schmidt]

On Sep 12, 2011, at 08:30, Anders F Björklund wrote:

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

Honestly, it's only ever confusing to me whenever you bring up the distinction. In this sense, I am that casual user you mention, and I suspect most of us are. Binaries, packages, archives, whatever you want to call it, they're all synonymous to me: it's software compiled on our central buildbot server and distributed in compiled form to our users.

The package manager that is available to install these is called MacPorts.


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

I'm against change for the sake of change, especially if it kills support for Tiger which, at least in terms of MacPorts base, otherwise works fine.