MacPorts 1.5.0 and binary packaging / New improved Guide

Anders F Björklund afb at macports.org
Tue Jul 10 05:41:23 PDT 2007


markd wrote:

> http://homepage.mac.com/duling/macports/guide.html
>
> Comments still welcome on the Guide so far.  It needs some color css 
> work
> and other css formatting, but I'm focusing on content and readability.

There are some common typos in it like "OS X" (Mac OS X) and "Xwindows"
(X Window System) and it should probably be less Apple/Mac OS X centric
(i.e. should mention explicitly that 2.1-2.5 applies to Mac OS X, and 
say
something instead of "Apple-supplied" - like vendor-supplied, etc 
etc...)

It would also be nice if it could mention "open source and free 
software",
instead of just saying "open source Unix software" and not mentioning 
GNU ?
This is IMHO also another reason why it is important to get License 
metadata
into the ports, as it is now you'll have to dig through 
homepages/licenses.

You can look at the old guide for some hints, it uses "third party 
software"
and has much more info on the common heritage with the BSD 
Ports/collections.
A "MacPorts for people used to *BSD Ports" section might even be a good 
idea.
Besides regular Mac OS X, MacPorts is also usable on FreeBSD (with 
GNUstep).


> I don't feel competant to write Section 7, "Packaging Ports into 
> Binaries".
> Can anyone who understands the packaging process throw some text at me 
> on
> this topic?  Doesn't have to be much or pretty, I can rewrite it but I
> just something more or less technically accurate to start with.  Or 
> point
> me to a similar section in another package manager if that is possible.
> I'm just not that familiar with the whole topic and the manpage doesn't
> say that much.

I will try to be of some assistance about those, we can take either in
the regular guide xml or if you're doing some kind of parallel guide
we can discuss it here on these mailing lists or on some Wiki page...


As it is now we have two kinds of binaries: ARCHIVES (.tgz, .tbz, etc)
and PACKAGES (.pkg, .rpm, etc). Eventually these might both be able
to use the same XAR archive, but as of now they're still separate...

The archives are created with "port archive" or by enabling archivemode.
They can (confusingly!) be found under /opt/local/var/macports/packages
with subdirectories for each platform (e.g. darwin) and arch (e.g. i386)

The packages are created with something like "port pkg" or "port rpm"
and are found in either the work directory or /opt/local/src/macports.
Since .pkg is a dir bundle, it is converted to one file with "port dmg".

The main differences is that the archives are used within the port 
system,
to avoid having to rebuild a port from source, and that the packages are
used outside the port system, without even needing MacPorts installed.


Besides the binary packages, we also have source packages. These consist
of the Portfile and all needed files/ (patches and other supporting 
files),
and they come in either ".portpkg" (XAR) or ".nosrc.rpm" (SRPM) flavors.

Normally there is not much need to use source packages, since the binary
packages can be built directly from the ports tree (whether rsync or 
svn)
but they are useful for port submissions or for storage of older 
versions.

In order to build a new binary from a source package, all the 
corresponding
distfiles are also needed. Normally these are only kept around as 
checksums,
but can be mirrored locally - or even included in the case of 
".src.rpm".

When building packages, all dependencies must be installed from ports or
archives - installations made from packages do not help and must be 
redone.
This is because the binary packages are *not* registered within 
MacPorts.


Hopefully that should be enough to start, and let me know if I am 
mistaken...
--anders




More information about the macports-dev mailing list