Binary repo for GSoC?

[Anders F Björklund]

Erik Österlund wrote:

>> In the scope of how the student summer assignment is written, it
>> _seems_ to be more about getting MacPorts AutoBuild deployed and
>> provide those destroots (as archives) for the regular port users ?
>> But I think that one new goal could be to either make a version of
>> pkg(1) so it works without Xcode, or have it build .pkg too perhaps.
> 
> Yeah so this is where I'm confused! What it seems to be about I thought was only handled.
> 
> From the description it says:
> 
> "This also includes to cleanly separate building software from installing it, using "real" binary packages."
> 
> This "also" seems to be what you've been discussing here, right?
> The other part, which seems to be the main thing, says:
> 
> "This project consists in working in concert (or cooperatively) with whomever does (virtual chroot) to setup a mechanism to automatically build packages, send reports on failures and implement a distribution mechanisms to allow users to fetch binary packages."
> 
> This seems to be about the distribution/deployment of the stuff and having dedicated build machines, spitting out binary packages. This is what I thought was already done.
> 
> If this is what it seems, I am very interested in doing this, but I'm not quite sure if this is, as Anders said, what it _seems_.
> 
> Can somebody verify this? Is it about binary package formats, a build distribution system, or both?

I'm thinking that it won't be about "real binary packages",
but that it should work with the .tbz2 archives from MPAB ?
(featuring the +PORTFILE and now with @pkgdep in +CONTENTS,
but still requiring the port(1) command in order to install)

These would then work with the "archivefetch" phase (in 1.9.1),
and have their .rmd160 digest verified against the known keys.
Those generated archives are signed using something like this:
openssl dgst -ripemd160 -sign privkey.pem -out archive.tbz2.rmd160 archive.tbz2


Once that is working with port -b, and the infrastructure is in
place to build archives, log results and serve public archives -
it is time to start on a pkg command that doesn't need all of MP.
It would need some kind of INDEX, of which packages are available.

If you use port(1), it would just look in the "PortIndex" but that
doesn't say which are available as binary and which are source-only.
As with the @pkgdep, it would also need version(_revision+variants)
information added to all (lib,run) dependencies and not just ports.


Preferrably the pkg(1) command would still update the MacPorts
registry, so that you could install some ports and some packages ?
(i.e. build some from source, and install others from binaries)
The inability to mix is another shortcoming with the current *.pkg.

So you would either do "pkg add foo-1.2_3.x86_64.tbz2" or use
"pkg add -r bar" and have it look in the pkgindex for the latest.
(alternative use some kind of "Latest/*.tbz2" server symlink hack)
But that wouldn't need all the ports files / the entire ports tree.


Considering it has to work with the MacPorts infrastructure,
it should probably be using Tcl in the "medium" time range ?
It's possible to use some shell script hack to get it going,
and hopefully both port and pkg will be Objective-C eventually.

But reusing as much code as possible from the regular base
is a good idea, especially if needing to access the registry.
Though it would be nice if it was available as a separate
installation, so that you wouldn't need Xcode for MacPorts...

--anders


PS.
Yes, this is (intentionally) similar to how it works in FreeBSD:
http://www.freebsd.org/doc/en/books/handbook/packages-using.html

You would use curl rather than fetch, but otherwise it's similar.
Just like "port install" and portinstall are, or "port lint" etc.