Binary Packages (again)

Anders F Björklund afb at
Sun Mar 13 04:11:34 PDT 2011

Joshua Root wrote:

>> Saw that "binaries" was on the summer agenda again ?
>> Not sure what it means, the pkg/xpkg and package/rpm
>> paths are still open if anyone wants to venture there.
> It would preferably be "real" packages, since the downloadable archives
> stuff is mostly done.

With "real" packages, I mean the ones where the metadata
(header, control) is separate from content (payload, data)
Such as .deb and .rpm (or the proprietary .pkg), but unlike
.tgz and friends - the ones we are just calling "archives".

Even if you include metadata in some random +FILENAME,
you still have to decompress the entire container first ?
Of course, if the metadata isn't even recorded / included
there is no alternative but to use archives and portfiles.

>> But assuming that it's mostly about the archives and
>> providing pre-built destroots, like those MPAB .tbz2...
>> So I added @pkgdep to the +CONTENTS (like in FreeBSD),
>> to record the versions/revisions of the dependencies.
>> Hopefully that could be of _some_ help, when trying to
>> install from archives only (i.e. the "port -b" flag)
>> Real packages would be better, but archives is "OK".
> It would be an interesting exercise to see just how far you could get
> going solely on the +FILES in the archive with no ability to parse
> portfiles.

There's some big assumptions made, with the current code...
(which should be improved, it's more of a proof-of-concept)

The port you are building, and all lib/build dependencies:
* are included in the portindex (no local-directories-only)
* are the latest version available (not using the -n flag)
And for the (version_revision-only) dependencies, also:
* are using default variants (as variants are not recorded)
* are using the default arch (architectures are not either)

Hopefully those should hold true for the automatic builder ?
If not, someone knowledgeable should improve portarchive.tcl

    # Create some informational files that we don't really use just yet,
    # but we may in the future in order to allow port installation from
    # archives without a full "ports" tree of Portfiles.
    # Note: These have been modeled after FreeBSD type package files to
    # start. We can change them however we want for actual future use if
    # needed.


More information about the macports-dev mailing list