Binary Packages (again)
Anders F Björklund
afb at macports.org
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
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
More information about the macports-dev