Clearly we're having a semantics issue here. MacPorts names them archives: please review how they're actually handled.
>>> 1. What process/script creates all the packages for all the ports? Where >>> is this documented? >> >> Port does it itself, the archive and unarchive phases. The server-side >> scripts (don't forget autobuild project as well): >> https://trac.macports.org/wiki/archives > > I'm sorry, but archives != packages, so in reality, the port(1) command is > not creating packages in that scenario at all. ... > > You're a long way from binary packages with just archives alone, I'm afraid. > :( >>> 2. The resulting packages are in what format? .pkg? .mpkg? .deb? .other? >> >> tgz, tbz2, etc. >> You can create installers using pkg and dmg, but those are a different topic. > > If we're discussing binary packages, they're really one and the same topic > since you have to consider how the user is going to install them. As we've > just established, "tar --unlink -xpzf foopkg.tbz2 -C /" is just not going to > cut it in providing a genuine installation experience for foopkg, so this > implies a tool being run, either from the UI or CLI (preferably with options > for both). The user is not installing them. MacPorts does. Please review the source code of MacPorts for the archive and unarchive phases. >> Dependencies are handled just like any others: >> library and run deps are installed/built first. Since the binary >> distribution doesn't need the build_deps, they are skipped. This is why >> I've had previously reported a lot of ports having their dependencies >> incorrect. > > Again, you are assuming that the ports collection is installed and can build > your deps. That's not package management, that's the system we already have > today and have had since day one (practically). An actual package management > solution would (and should) work in the absence of any macports installation > since macports is really just for people operating the assembly line, it > shouldn't be something end-users ever have to know or care about (or install > DevTools in order to use). Right, so this is a giant semantics issue. Arguably, MacPorts is not built to do "packages"--ever. Time for a new project, or we can sit on our hands and not use archives either. >>> 4. If you've been building all the ports since 1.9 came out, what's your >>> fail/success rate right now? Is this data being captured somewhere? >> >> http://lavergne.gotdns.org/macports/ > > I must be missing something. This seems to capture ticket data and allow you > to browse a bunch of archives. I'm not seeing any build fail/success logs > for the individual ports, is what I meant. > > In any case, no \o/ here so much as a /o\ since what you describe isn't > packages yet or anything even really close. :( I'm not going to keep defining "package" versus "archive". MacPorts' functionality allows it to download binaries and install them. No hours of building. Please stop beating the semantics horse over how I titled what it does.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
