Jordan K. Hubbard wrote:
You're a long way from binary packages with just archives alone,
I'm afraid. :(
Archives include the build folder, and the Portfile. To say we'd
ruin people with archives you'd have to also agree we already ruin
people with the way we run MacPorts entirely.
Please don't confuse passive data with active data. Sure, the
archives can and do include the original "port" metadata, but they
don't actually include the "package" metadata necessary to make
that port work stand-alone in the absence of macports (which,
again, is a goal here since macports drags in an entire devtools
suite and still puts the burden of building some amount of software
on the user).
The necessary metadata could easily be added to the archive metadata
files, in a format similar to FreeBSD's. Based on your input even the
old xar-based xpkg format was revived, to make it possible to add
structured metadata (XML) rather than just tar/txt...
But since nobody is using it, it's just dumping some basic metadata
(name, version etc) and a copy of the Portfile "just in case". The
main contents would be the build state and the destroot, so it is
only intended to help caching rather than for packaging.
That part is either not been done, or done in a limited way for a
few popular package formats like .pkg, .rpm and .deb (though some
of those package formats have bitrotted some and probably need
updating). This translation code between "port metadata" and
"package metadata" is limited since it only knows how to translate
a certain number of runtime actions, like foo depends on bar, or
foo/blah should be installed with certain permissions, it doesn't
know how to translate the actual post-installation actions that
many ports have inside those Portfiles. That is why those package
targets have largely bitrotted - they only do the job for a certain
subset of the ports collection and nobody quite finished them all
the way such that all ports could be truly packageable.
The .rpm was intended to be used internally, just like .deb are being
used in the Fink project. So that each install/upgrade action would
first build a package, and then install said package. The furthest
attempt so far was in the "dp-lite" branch. As I see it, it (internal
packages) was rejected - in favor of just using port archives.
The pkg/mpkg/dmg should still "work", but they only export things for
use outside of MacPorts and lack interesting runtime options (and
data). And since they are not Open Source either, it seems like a
poor choice for a packaging format for MacPorts ? Besides the missing
uninstall and lzma compression and all the other shortcomings, that is.
I also never said we were "ruining" people, I simply said that if
you were already required to install MacPorts itself (the
infrastructure and ports files) then you are providing MacPorts,
same as always, and not a public package collection. Just making
the archives available is more of an optimization which the project
could, someday, offer to its users as a way of skipping some of the
build process for certain popular projects, but they're still going
to be calling out to the compiler toolchain and still rebuilding
anything that a set of custom variants have been specified for
(since you won't have the right "canned archive" available) so it's
just an optimization, it's nothing particularly new or innovative.
That was the decision... Always require MacPorts (base), Developer
Tools and the entire Ports tree too. And indirectly also always
require Terminal, since no free GUI was completed.
I'm still waiting for something new, like an actual package
collection which does not require anything but a very minimal Tcl
runtime which is distributed in the packages itself, making those
packages genuinely stand-alone and worthy of the name.
The previous approach was for a "pkg" command, that would do mostly
the same as "port -b", but *not* require the Developer Tools. i.e.
Mac "pkg install" would be similar to BSD "pkg_add".
I'm not sure why the runtime has to be in the packages themselves, it
seems less redundant to have a small "installer" program installation
contain that ? But either way, it would have been a "MacPorts
Developer" that would offer to build things from ports and a
"MacPorts User" that would simply install pre-made archives. And for
that to work better, archives would need some improvements (extra data).
I started on the pkg.tcl command, but stopped since MacPorts was
getting rewritten in Objective-C and SQLite anyway and there were no
pre-built archives ("remotearchiveurl" *) available...
* http://trac.macports.org/ticket/8571
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
