Weissmann Markus wrote:
It's much easier to do packaging and testing, when the rate of change
slows down. The automated build and packaging process is being
revised now (using it to build RPMS), and that is very useful to have
either way.
This is great. I think we can talk about splitting the tree as soon as
this features is finished and we have a build-server that reports
about build errors.
Having a build server is more of an infrastructure/resource question,
but there is a lot of work being done with tracing and logging - I'm
more doing the oldfashioned approach with a chroot and scripting...
But the Koji* build system is kinda nice looking, otherwise... :-)
Impatient or out-of-date users will occur either way, the easiest
path to help them is probably have an updated ports list for easy
viewing - such as a web page with versions and recent updates.
The out-of-date users will be far less if we provide RPMs. The
impatient ones are often also those who find the bugs in the first
place.
It's also possible to provides archives (tgz) for impatient developer
users, within the port system itself. But both are being built anyway,
it's the same destroot contents in both - no matter the wrapping.
Having portable MacPorts also helps, easier to build/test on BSD/GNU.
--anders
* see http://koji.fedoraproject.org/koji/
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
