Binary Packages (again)
Jordan K. Hubbard
jkh at apple.com
Sun Mar 20 23:48:16 PDT 2011
On Mar 13, 2011, at 4:11 AM, Anders F Björklund wrote:
> 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".
I'm not sure that I understand how the distinction between "real" and sub-functional packages is a function of where the metadata is stored. My understanding of the "archive" format has always been that it proves some, but not enough, of the +CONTENTS file metadata necessary to really represent, from a purely functional standpoint, an installable package. If it had more such metadata, at least as much as reasonably expected by the FreeBSD pkg_install tools (and I know that I still owe folks a port to Darwin of those tools - got distracted by other things), then MacPorts archive files would be no more or less installable than arbitrary binary packages on FreeBSD, and that meets the criteria of "good enough", does it not? It's not a .deb or .rpm, no, and it suffers from some funkiness like:
> Even if you include metadata in some random +FILENAME,
> you still have to decompress the entire container first ?
Yes, in /tmp - it was a lousy design decision and I regret it to this day (I had some weird notion of "transactional installs" which never ended up being truly transactional anyway) but on most Mac OS X systems that's still the same volume as the target file, so at least you just get a temporary unpack followed by a rename of each file/dir into place and it's the same amount of disk space, transient or otherwise, either way in the end.
> Of course, if the metadata isn't even recorded / included
> there is no alternative but to use archives and portfiles.
If you were using the pkg_install suite, the metadata would be recorded for subsequent pkg_delete / pkg_info / pkg_update operations. Again, it all comes down to the fidelity of the metadata in those "smart tarballs" *BSD calls packages.
More information about the macports-dev