On Oct 26, 2007, at 13:07, James Sumners wrote:
I was mulling this over last night as I was going to sleep. It seems to me that the port maintainer could be relied upon to build the package for his respective port(s). That way, MacPorts doesn't need to hunt for a build machine.
The user's machine is unlikely to be clean. For example, the user may have other ports installed, and when the user packages a port, that packaged port may inadvertently be depending on some of the user's other ports without his knowledge. Better to have a build machine (or build machines) that can predictably and cleanly create packages.
Although, someone would need to step up and maintain a cross compiler port for the maintainers. That would make it easier for the port maintainers to build the packages. If they could do something like `port package +g4 +g5 +intel`, I'm sure the idea would go over a lot better.
Surely we don't need anything like that. Anyway, it wouldn't be a cross compiler port that we would need. Rather, each port would need to have this capability retrofitted. It would be very similar to the +universal variant we're already trying to retrofit into ports. I would much rather we continue working on perfecting that, rather than introducing ways to cross-compile things, a capability which would probably not be very well tested and therefore buggy.
Of course, there would then need to be functionality built into port to pull down binary packages instead of source packages.
Sure.
On 10/26/07, paul beard wrote:
On 10/25/07, Daniel J. Luke wrote:
On Oct 24, 2007, at 10:11 PM, James Sumners wrote:
Why doesn't MacPorts supply binary packages?
No one has worked on it recently.
If you're interested, I'm sure we would be interested in your help.
Is there a status document that addresses where things stand on efforts like this? I haven't been all that successful at building packages within port (port pkg foo where foo is something i would rather not build again on a second machine). I think I may have resorted to taking the output of "port contents" and wrapping it in a tar or zip command, but that doesn't add any of the magic of receipts and the rest of the stuff that makes a ports system worth using.
if packages, especially meta-packages, could be licked, it would make things like gimp and gnome a lot more accessible, as there wouldn't be the huge build delay. I'm not a coder of any merit so I can't put my shoulder behind it, but it would be of interest to know if the core team sees any value in packages (possibly as a component of checkpointing the releases: as of a given release, one could be assured that a given subset of essential/popular ports could be installed as source or as packages). It may be one of those things that is nice to have but lack any support on the core team or in the user community.