macports fetch suggestion

[Anders F Björklund]

Ryan Schmidt wrote:

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

It's so that you can install pre-built packages, without MacPorts.
It was somewhat useful for adding software to Darwin OS, earlier...
So it fills the same niche as the (proprietary) Installer and .pkg,
but under the GPL license ? Accidentally it also supports uninstall.

The FreeBSD ports system (and packages) are much more similar to MP.
Main difference is that it uses BSD Makefiles instead of Tcl Portfiles.
Described on http://www.freebsd.org/doc/en/books/handbook/ports.html
Using the "portupgrade" tool, it's not all that different from MacPorts.

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

Yes I know, but this could just as well move to outside the port ?
And it has some "strange" side-effects, when just looking at it:

$ port installed MacPorts
None of the specified ports are installed.

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

I'm wondering how many those individuals/organizations are, and if
they wouldn't be better off using the new archivefetch/tarballs ?

Otherwise it seems more like using MacPorts to build outside things
like bundles and installers, that it isn't really suited well for...

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

The problems are just all the limitations of the Installer.app,
and the lack of integration between those packages and port(1).

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

Yes. But why "separately" ? i.e. does it have to be that way ?
Ideally MacPorts should be able to handle both types of users.

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

I was thinking the opposite, that MacPorts shouldn't be a port.
An automated uninstaller would be nice either way, though...

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

Keep the current definition then :-) No argument about the English.
And it's not like you *have* to remove the old crusty code, either.

--anders