Binary repo for GSoC?

[Erik Österlund]

Thanks for the clarifications. Now I have a clearer view of what is anticipated, and it seems like it is what I was interested in doing in the first place! I'm interested in applying for this GSoC and getting it done.

Now what?

- Fisk

23 mar 2011 kl. 10:32 skrev 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.
>