On Aug 30, 2007, at 2:48 AM, Anders F Björklund wrote:
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"
This might be a nice mechanism for doing the initial installation of example configuration files. I wouldn't want to go too far and do what Debian does -- try to manage configuration files for you. It's not so bad when they ask if you want to update/diff/merge the files (although that's annoying and in my experience a bad method for handling software upgrades) -- it's downright dangerous when they try to auto-merge configuration based on scripts (think apache, sendmail, exim, etc).
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.
I like subpackages -- especially for things like -server vs -client, but I'm not so sure about debian-style header packages -- there's not much advantage to not shipping headers (save a few k), and it complicates the dependency tree and requires the user to select multiple packages for installation. I also admittedly have a heavy developer bias here.
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"
I agree that we need more meta-data here -- especially licensing information, since there are redistribution limitations depending on the license.