Binary repo for GSoC?

[Anders F Björklund]

Joshua Root wrote:

>> Last time I mailed about binary repos it seemed like almost all was done except for adding licenses and deployment.
>> When I checked for wanted GSoC projects I could still see this one up though.
>> 
>> Is the page for wanted GSoC projects not updated or is this project still wanted? In that case I'd like to do some shit!
> 
> That project description could probably do with some more clarification.

I updated the original description, which was from GSoC 2007:
http://trac.macports.org/wiki/SummerOfCode#binaries

The "virtual chroot" mentioned was finished with "tracemode" (?),
but I think that MPAB is using a more traditional chroot setup.

I also removed the explicit mention of the now obsolete PowerPC
for a more generic "universal" and split off #livecheck project.

Also added a mention that archives are compressed (default .bz2)
and signed (default .rmd160), both should be implemented already.

> The project would be about packages (as opposed to archives), that is,
> binaries which contain enough metadata to be used without having the
> ports tree handy, and tools to work with them.

I don't think that MacPorts will be using "real" packages ever,
so the archives will need to be extended with "enough" metadata
to be used without the ports tree. There should still be a tool
done that can install them, without needing Xcode or ports tree.

I called it "PkgIndex" for now, which is PortInfo with @pkgdep.
The tool would still need to work with the registry, so that
the installed files from binaries are known to the other ports.
Unlike installing from .pkg, which doesn't mix with port(1) ?

> There's also work that could be done on the server-side autobuild stuff,
> though I'm not sure if there's enough there for a whole GSoC project.

I added some ideas like building +universal or other +variants,
for instance building both +aqua and +x11 variants of some ports.
This quickly explodes exponentially, so should be kept minimum.
It's perfectly alright to only do default variants initially...

I'm not going to do any mentoring or further development though,
just thought I'd help document what was/is already implemented ?
There's a lot of stuff that still need consideration, for instance
activate and deactivate scripts from packages or checking licenses.

--anders