Gary Kline wrote:
On Tue, Mar 20, 2007 at 08:52:37PM -0700, Garrett Cooper wrote:
Hi all,
I know this may be more of a questions@ type of question, but I was
wondering if some people could provide me with short history (beyond the
last 3 months) and the tipping points of portmaster vs the portupgrade,
portinstall, etc tools.
I know portmaster is a bourne shell script and the portupgrade,
portinstall, etc scripts are ruby based, so that's a given.
I just want to know if there's a given solution that I could work
with in improving the ports system and forge into a unified port/pkg
management frontend (using bourne shell scripts and C), combined with
the current package management tools in place (pkg_add, pkg_version,
etc), as part of a Google Summer of Code proposal.
To Garrett and my days-of-yore ports gang, and the maintenance
and build guys,
How about this idea for integrating into a new ports/package
project: say for people with a fast I686 who wanted -O3 and -pipe
and wanted his packages built remotely rather than his own
computer. Would be be posssible to build a package, custom
(according to one's /etc/make.conf) on FreeBSD's servers, then
fetch the *tgz package back? Kernels, and worlds would reside
on the remote server for only a few hours before being
automatically cleansed. This would be super for everything from
a i486-166MHz with 32Megs that was serving mail *only*, a slow
to moderate i686, or even an AMD 2800. Building locally is
sometimes the only way. But if users have slower servers and
there are no current packages (i386), why not let the builds be
queued?
(Please 'cuse me if this is too wild, but I just had a full
double espresso and am bubbling over with ideas.)
gary
Thank you very much for your help in trying to make a great OS even
better.
-Garrett
Eh, it's a wishful thought but unfortunately everyone has a large list
of dependencies that will (most likely) differ from the rest of the
bunch, from languages, to options, to library versions -- doing that
wouldn't be unfeasible.
However, if you want a faster method to compiling stuff, there's distcc.
It's not exactly the best thing to use all the time, but if you work
with port maintainers and stuff gets more standardized, distcc can be an
effective way to building packages across multiple machines. Apart from
that, there isn't much way to do anything... apart from setting up your
own higher powered PC with a set of your desired options and build from
within jails, and package as you go. A i386 can build different archs
binaries (amd64, ppc, etc), in-so-much as it can find the right info
(headers, libraries to link against, etc).
That's a thought for your PCs project :).
-Garrett
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
