Binary Packages (again)

[Anders F Björklund]

Jordan K. Hubbard wrote:

> 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?  

Yeah, if MacPorts did that it would be more than destroots...
FreeBSD/Slackware/ArchLinux/etc tarballs are "packages", sure.
But if those binaries still require a full ports tree to get
the needed information, it's not more than just "archives".

Those archives are still much better than nothing, though.
Even automatic building and throwing the result away is...
Though I don't think you could work with just the destroots,
for anything more than a pretty "basic" binary installation.

But yeah, MacPorts could probably have "good enough" packages.

> 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.

No, it's not... You need to download the entire content,
just to get at the metadata ? And also unpack all of it,
probably using the slowest decompression available: bzip2.
So it both takes more disk space, and much more memory too.

It's possible to work around it, by exporting an INDEX and
a plist MANIFEST to separate files, but still a shortcoming.
And I don't think that it has even *started* to make it all
transactional, including the shell scripts encoding within ?

--anders

PS.
FreeBSD/ports/amd64/packages-8.2-release: (21,106 packages)
1.3M	INDEX.bz2
 13M	MANIFEST.bz2
 31G	All/*.tbz