Owen G wrote:

You are aware that there exists
1. ports = source = must be compiled = "make install" (as above)
2. packages = executable packages = precompiled = "pkgadd -r . . ."

Whilst your description of ports and packages is correct...

So unless you're running a custom kernel, there's no advantage of ports
over packages.

...this is not.

Ports are useful :

1) For any package with multiple compile-time options (e.g. apache) where *you* want to choose those options rather than be stuck with the ones the *package* was compiled with (c.f. Linux rpms)

2) If you want to be as up-to-date as possible - packages take time to pre-compile and can lag the ports tree a little

3) If require the source code (for maintaining local patches; because another port or some other local software needs it)

I'm not aware that a custom kernel has any relevance whatsoever. Perhaps you meant "unless you have used some cpu-specific compile flag in make.conf" but I don't think even that would make a difference.

Also, ports and packages are managed much more easily with a tool like portupgrade or portmanager. I prefer the former because it has never core-dumped on me, and feels more robust and well maintained.

If you have multiple machines you keep in sync, then portupgrade -p or pkg_create -b can be used to create local packages with *your* compile-time options that other local machines can use.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to