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
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.
Landon Fuller wrote:
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).
I wasn't thinking of diff/merge of configuration files (it does indeed sound very interactive and/or rather dangerous), only to compare/move configuration files. FreeBSD (with scripts*) and RPM (automatically) does this for you, for instance... But the first step is to add a setting to the Portfile to signify which are configuration files. The install/uninstall script solution is currently not possible in MacPorts, since it doesn't feature any such scripts/targets at the moment. --anders * see http://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html
On 2007-08-30 11:30:39 -0700, Landon Fuller wrote:
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.
This depends on the libraries: sometimes it saves a lot (I can see that on my old laptop with its 9-GB drive). Remember that -dev packages are not just header packages; they also contain the static library. But the most important point is that one can install several versions of a shared library (useful in case of API change[*]), whereas if the headers (and static library) were included, there would be a conflict. [*] This could solve the well-known breakage in MacPorts when one upgrades some library, sometimes making packages depending on it no longer work. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
participants (3)
-
Anders F Björklund
-
Landon Fuller
-
Vincent Lefevre