Binary repo for GSoC?

[Anders F Björklund]

Joshua Root wrote:

> On 2011-3-22 04:30 , Erik Österlund wrote:
>> Hi,
>> 
>> 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.
> 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.

On the other hand, the decision much earlier was to extend the archives
with "good enough" information so that they would work as packages too.
Rather than switching to another package format, such as rpm or xpkg...

And the suggestion was to provide a pkg(1) command, to work with them.
The idea was to make it similar to the pkg_* tools on FreeBSD, just as
the port* tools on FreeBSD are similar to the regular port(1) command.


But there's some previous work to make MacPorts work with rpm packages,
just like Fink works with deb packages. Or to use the xml-based "xpkg"
format as a replacement for the tarball "tgz" for the better metadata.
Though there's not that much practical difference between the two, as
it is mostly a difference of using +METADATA or <metadata>, really ?
I don't think either has been worked on since Darwin was still Open:

http://trac.macports.org/browser/branches/dp_light-olegb

http://web.archive.org/web/20061230221957/http://www.xpkg.org/


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.

http://trac.macports.org/wiki/SummerOfCode#binaries

http://guide.macports.org/#using.binaries


The .pkg are "easy to use", but have all the misfeatures of Installer:
* no uninstall (!)
* bad compression
* proprietary bom

BTW: if requiring Leopard, as supposed to still supporting Tiger,
one can build xar-based "flat" packages instead of using .dmg...
This is done by changing the package.flat variable over to "true",
and will make the .pkg into files rather than bundle directories.


The main decision is whether the binaries should work with the
macports registry or not. That's probably the biggest difference
between the "archives" (tgz) and the "packages" (pkg) at the moment,
aside from the format itself and whether it contains dependencies.

But MPAB building .tgz or .txz archives (i.e. "port archive") and
.dmg or .pkg packages (i.e. "port pkg") should be straight-forward.
I think all the fetching and verifying and such is in place now ?
At least for using "port -b" to install them, rather than "pkg"...

--anders