Features desirable for packaging

[Anders F Björklund]

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