Features desirable for packaging

[Landon Fuller]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070830/9e1b3b55/PGP.bin