[GSoC][Binaries support] Architecture

[Felipe Tanus]

Hello,

Thanks for all the replies. After reading this discussion, reading more about
portfiles on the docs and taking a peek at the mp and mpab sources, I
would like to add a few points

*compression: Even if xz is arguably better than tbz2, in the GSoC
scope we should focus on binary distribution, so I believe that it's
better to stick with tbz2 for now. Maybe we can patch macports for using xz
later.

*signed packages: I was not aware that macports already have a sign
system, and mac doesn't support natively GPG. Sorry about that, I'm
quite new to both mac and macports. Since we already have openssl,
let's keep using it for binary packages. Right now I think that the
best option is signing the tarball itself, not its content or in the
index, because it is simpler. But I might take a deeper look in this
soon. I must also check in macports source the current implementation
for package sign.

*Build system: I've been looking into MPAB, and I think that rewriting
it on TCL would be a good thing, and maybe this could be done in this
GSoC. Does this seem reasonably? I'm not quite sure about the
complexity of this task. Anyway, we should modify it to fit with our
needs, that is, include package signing, format output to fit in the
repository folder structure (if needed), keep the build logs, send
e-mails and wrap this in a simple web interface to check the results.
Since this is a considerable amount of changes, I think we might port
it to TCL.

*macports integration: I believe that we can first add binary
support for the existing port tool. The interface can be something
like "port install from binary xyz" and "port install from source xyz"
with some default. The TCL env problem doesn't exist in the
integration. In order to work, a binary package should have only three stages:
fetch, extract and destroot: the other phases are skipped. There is
more to be added to port; We need, for example, keep a track if
certain package was installed from binaries or from source. When
update the system, the updating packages should respect the former
installation (maybe we can do "update from source" or "update from
binary" to force one way or another, but this should not be the
default). Maybe binary can be a variant, but sounds like a ugly hack.

* Binary only tool (pkg): To ship a new tool, some of the current
implementation can be used, like dependency check and 3 installation
stages. To create this tool, we have the problems like TCL env. I
think it would be nice to have a port for port tool, one port for pkg
tool, and one port for TCL env helper, and try one dependency
approach. But I don't think we should focus on this tool in GSoC. My
point is that the pkg really should exist, but first things first.
Would be great create this tool, but I'm a little concerned about the
schedule as a GSoC project, not as a FOSS project. Do you guys think
it's possible to add this tool to my proposal and finish it in time?

Also, thank you for explaining the variants and universal binaries. It
was really helpful.

[]'s

-- 
Felipe de Oliveira Tanus
E-mail: fotanus at gmail.com
Blog: http://www.itlife.com.br
Site: http://www.inf.ufrgs.br/~fotanus/
-----
"All we have to decide is what to do with the time that is given us." - Gandalf