Joshua Root wrote:
So sticking with the archives seemed like a reasonable approach.
I do think archives should be the short-term goal. The true binary
distro utopia Jordan describes will naturally be a lot more work.
That is what I figured, so any packages will have to be external "for
now".
Currently there is support for PKG (mdmg) and RPM (4.4) and XPKG
(sortof)
To install them, one would use Installer.app or rpm or xpkg as
appropriate.
But they won't get recorded in the registry, and won't know about
ports...
So you need to build packages for *everything*, rather than mix and
match.
There is still the problems with licenses, both with ports and with
OpenSSL.
My personal response is, "Yes, we know that binaries would be a
great
feature to have. Now can we stop talking about it and write
code?" :-)
Because in the end, this feature request, like every other, is
waiting
on a volunteer to produce a patch.
So you want the dp_light branch updated ? Or a patch for xpkg ?
Or should we talk about which code we are about to patch ? ;-)
I figure resurrecting the patch in #8571 would be a good start. Then
grab archives from MPAB and make them available, and see where
things go
from there.
Remote archives (#8571 or #10919) would be a start, but it would need
to be moved to a separate new phase (e.g. "bindist" or "fetchpackage").
It would also need to grow the basic MD5 and GPG features, presumably
something like PACKAGES.TXT and *.tgz.asc or something similarly simple.
"port install" should also be extended to work with archives as well
as portdirs, by extracting the +PORTFILE and +STATE from the archive.
It should be able to either take a local file path (or a file:// URL),
or a remote archive location (by fetching to a temporary file first).
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
