The source code says you aren't. Shall I construct a set of arch^H^H^H^Hpackages which fail to work, just to prove you haven't looked at the source code closely enough? :-)
- Jordan On Sep 20, 2010, at 2:27 PM, Jeremy Lavergne wrote: > We are a package repository. > > "Jordan K. Hubbard" <[email protected]> wrote: > >> >> On Sep 20, 2010, at 2:09 PM, Jeremy Lavergne wrote: >> >>>> I'm sorry, but archives != packages, so in reality, the port(1) command is >>>> not creating packages in that scenario at all. Archives are missing a >>>> bunch of the necessary metadata to quality as packages, the simplest >>>> example of which are deletes. If you upgrade a port simply by extracting >>>> newer and newer archives, you will gradually accumulate cruft until such >>>> time as certain ports actual fail to work due to legacy bits being >>>> detected (and acted upon) when newer versions of the software were written >>>> with the assumption that those files were long gone. You can potentially >>>> create a deletion list simply by "diffing" two archives, but that simply >>>> leaves you with the next bit of missing metadata, namely the files to >>>> explicitly migrate from version X to version X'. There are also the post >>>> install actions to consider (add a role account user, run a special >>>> post-install script, etc) which archives do not provide. Archives are >>>> essentially "dumb", and even the über-simplistic > {Free,Net,Open}BSD package manager makes its .tar.gz package files "smarter" > by including a special manifest file (+CONTENTS) that has a whole bunch of > possible actions embedded in it. >>>> >>>> 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). >> >> 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. >> >> 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. >> >> 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. >> >> - Jordan >> > _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
