macports fetch suggestion

[Ryan Schmidt]

On Sep 12, 2011, at 09:34, Anders F Björklund wrote:

> Ryan Schmidt wrote:
> 
>>> 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.
> 
> The archives could be extended to packages with a few extra metadata, at least there's nothing fundamentally different from the MacPorts "archives" and the FreeBSD "packages" in terms of format. But there seems to be little reason to keep "supporting" RPM if it is never going to be used directly anyway. That goes for both MacPorts and FreeBSD... Stick with them old tarballs.

I don't know why MacPorts contains any rpm code or what it was supposed to be useful for. I have no experience with rpm nor with FreeBSD or its ports system.


> And as far as I know, there's only one port using .pkg and that's MacPorts itself ?

The MacPorts port is a port like any other, it's just not intended for users to use; it's intended for the MacPorts team to use when preparing MacPorts releases. We make use of the "port dmg" feature to create a disk image of a Mac OS X Installer package of the built MacPorts software which we then upload and link to on our web site for users to download and use. This may be the only instance in which the MacPorts project itself makes use of MacPorts' dmg and pkg creation facilities, but it's also a documented feature of MacPorts that many other individuals and organizations use to package up and distribute software, so it's not something we should remove.


> Even if it should be mostly possible, making .mpkg and .dmg and shipping them separately, that's a lot of bundling overhead and update problems. And it's not like you can take those existing packages and just upgrade them with MacPorts either, you have to overwrite all of it with a brand new copy.

We have the capability of MacPorts to create standalone Mac OS X Installer packages, optionally wrapped in a disk image; that's discussed above.

Separately, we have the capability of MacPorts to download compressed tarballs of software built by the buildbot and install these into an existing MacPorts installation.

These are both useful functions.


I have thought that it would be nice if we could let MacPorts update itself, using the MacPorts port. When a user first installs MacPorts, instead of no ports being installed, the MacPorts port would be installed. Uninstalling that port would uninstall all of MacPorts, eliminating the need for separate uninstall instructions. Upgrading that port would upgrade MacPorts, eliminating the need for a separate selfupdate system, and with it the problems some users currently have accessing rsync servers. It would possibly complicate things if a user's MacPorts is unusable and they want to recover by reinstalling MacPorts from the dmg; the dmg installer would have to learn how to update the registry properly. Haven't really thought the idea all the way through but it interested me somehow.


> But the buildbot is a *huge* improvement, both for user "build time" and for distribution QA.
> 
> Just saying that if you're going to call the archives packages, might as well simplify things ?

Again I think it's only ever not simple when you talk about it. :) It's already simple for me. I just don't see the distinctions you make between archives and packages. I'll use either word at random depending on what pops into my head first.