It has been mentioned before, so I thought I'd summarize what features that could benefit the packaging targets (I'm thinking primarily of the "rpm" target here of course, but I'm sure it'd help pkg and deb targets as well): 1) Config files We need a feature in the Portfile to mark which of the install files are configuration. These files will then be handled specially when doing installations/upgrades/removals, in that any existing modified configuration will *not* be overwritten. It could also be helpful for implementing a similar feature in the regular install/activate target too. Syntax could probably be similar to "destroot.keepdirs" 2) Sub-packages When building binary packages, having everything in a single port increases the size of package dependencies greatly. Usually one doesn't need the developer files, so there's a whole bunch of headers and whatnot undesirable. Splitting these off into a subpackage called "*-dev" (from DEB) or "*-devel" (this RPM naming is already taken in MP unfortunately) helps here. Not sure about syntax here. It needs to list the files. 3) More metadata Some metadata is currently missing from the Portfiles. It would be nice if these could be added with MacPorts 1.6, but it does require a major update since the older "port" won't understand any such new fields added to the syntax. Extracting changelogs from svn might be nice to include too, but is probably not required until it has been fully automated. a) License metadata (http://trac.macports.org/projects/macports/ticket/7493) Currently all ports have license "Unknown", no matter what the actual license used. Example portfile syntax: "license GPL" b) Noarch metadata (http://trac.macports.org/projects/macports/ticket/12206) Currently all ports have architecture "native", no matter what the actual arch is. Example portfile syntax: "noarch yes" Neither of these are showstoppers for binary packages, but they would definitely improve the quality of them. Especially the "avoid deleting user preferences" and "don't require developer tools" I would consider rather essential... I'm sure we'll have some more concrete feedback when the first MacPorts 1.5 packaging run completes. Hopefully that'll be in time for sfiera's/jmpp's redesign of the webpage/database. Tentatively http://macports.org/packages/ --anders