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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
