Intel guy: FreeBSD Work (week #2) - big TODO list.

marino said:
Building isn't necessary -- the FreeBSD packages are available as binaries.
The only caveat is that they aren't signed packages, so that being a dealbreaker is the only benefit of building yourself that is gained.
I do need to get around to signing these things.
Click to expand...

I build PHP specifically with certain options (ZEND_THREAD_SAFTEY, MAILHEADER) and also other ports with some non-default options.
The number of ports I build with special options has decreased over time, though. But some will always stay "special".
 
I was thinking about the "Base-Extras" concept (nothing new actually). A separated tree developed exactly like Base but optional.

This idea would allow a very minimal Base, for instance with just one firewall instead of three. The rest in that separated tree, like the two others firewalls, Heimdal, GSSAPI, etc.

In practice something along lines to the user installing the minimal and later optionally:
  1. use freebsd-update to bring the desired extras (IDK if it would really be feasible);
  2. download the desired extras source-code, and rebuild the system.
Eventually an image could be made available with all extras included.
 
I've just remembered another thing: profiles and sub-profiles.

I am not talking about hard profiles like on Gentoo, that lock many behaviors of the system, but soft profiles which set ( but does not lock ) some defaults parameters per general user case, ie:

Default ---> today parameters

Server
|_ Secure server
|_ Specific user cases profiles...

Workstation
|_ Regular desktop
|_ Secure desktop

Then sub-profiles could also be integrated for specific areas:

Networking
|_ 1 Gbps
|_ 10 Gbps
|_ 1000 Gbps

Idealistic the user could export its configurations to something like a "buildsheet" to be later easily re-create ( and eventually share ) the configurations.
 
puretone said:
(flameSuit = On)

What's wrong with pkg sea -o ??
Click to expand...

pkg(8) is to search packages not ports. E.g. if you build from ports and mainatain you own repositories but doesn't build everything, pkg search will just return from the ports you built and not from all possible ports.
 
It isn't that hard to make your own search tool for ports. Here is mine (yes, it's old)
Code: 
root@kg-core2# cat /usr/local/bin/pinfo
#!/bin/sh
# @(#)port    1.0    10-nov-2001    T. Ingolfsen / KG4, Norway
#
# Just a quick hack to get any easier way to search for ports
#
NAME=`basename ${0}`
PORTNAME="${1}"
PORTSDIR="/usr/ports"

if [ "$1" = "" ]; then
    echo " ${NAME} - find a given port in /usr/ports"
    echo "    Use with '${NAME} xxx', where xxx is the name of the port."
else
    if [ ! -d ${PORTSDIR} ]; then
        echo " ERROR: ${PORTSDIR} doesn't exist!"
        exit 0
    fi
    cd ${PORTSDIR}
    make search name=${PORTNAME}
fi
During it's life, it had to be renamed due to some name collision.
 
Yeah, but I was talking about something like EIX which show supported options, what are defaults what are ON and what are not etc. and some other thingies.
 
rigoletto@ said:
pkg(8) is to search packages not ports. E.g. if you build from ports and maintain your own repositories but don't build everything, pkg search will just return from the ports you built and not from all possible ports.
Click to expand...

Surely. Particularly with a custom repo. But that doesn't take away that pkg sea -o can be used for searching both local / remote repos in parallel. The approach Tingo takes is very useful, a Golden Oldie. And then there's ports-mgmt/psearch ...
 
You must log in or register to reply here.
Back
Top