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. And as far as I know, there's only one port using .pkg and that's MacPorts itself ? 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. 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 ? --anders _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
