Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 May 2006 23:10:26 -0700
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Sideris Michael <msid@daemons.gr>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: ports structure and improvement suggestions
Message-ID:  <20060509061026.GA14039@pentarou.parodius.com>
In-Reply-To: <20060508200926.GA6005@daemons.gr>
References:  <20060508200926.GA6005@daemons.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 08, 2006 at 11:09:26PM +0300, Sideris Michael wrote:
> Hello everyone.
> 
> I am writing this email in order to "discuss" with you about the current structure of Ports. To tell
> you the truth, it is not really about the structure rather than the way Ports are handled by people.
> I will focus exclusively on building from source since this is the cutting edge really.
>
> [snip] 

What you've mentioned has been brought up before (I say this sincerely,
not as a BOFH-like attempt to dissuade the importance of what you've
said):

http://lists.freebsd.org/pipermail/freebsd-ports/2006-February/029872.html

As an administrator who __refuses__ to install portupgrade (for
almost too many reasons) and will only rely on the standard pkg_*
tools which come with FreeBSD, I'm looking at the situation from a
purely minimalist point of view.

What I proposed in the aforementioned thread was to have an actual
BIND-like configuration file (e.g. a tree) which contains individual
options which are set to yes/no per port.  There is a global scope
which applies to all ports, while individual ports can be adjusted
individually -- or overwride the global scope settings.  I proposed
something that applied to both ports *and* buildworld, which now
that I think about it, probably wasn't a good idea.  So here's
a modified version:

# No IPv6, and no X11
IPV6 = no
X11  = no

devel/gettext {
  EXAMPLES = no
  HTMLMAN  = no
}
www/apache20 {
  KQUEUE_SUPPORT = yes
}
www/suphp {
  CHECKPATH = no
  LOGFILE   = /var/log/suphp.log
}
net/cvsup {
  X11 = yes
}

Am I going to submit patches for this?  No, because it's above
my expertise level.  I'm also left wondering how this would
actually get implemented with the current ports setup (meaning
ports/Mk and share/mk).  The application this would have to be
in C (are you going to parse a config file like the above
using sh? ;) ), and would have to be "spawned" or involved
somehow via the ports/Mk framework.

The one advantage OPTIONS has over historic WITH_* knobs is
utilisation of /var/db/ports.  Probably wasn't a very good
default name for the directory though (db/pkg vs. db/ports;
newbies aren't going to know the difference, and even old
administrators may forget...)

What I'm basically trying to get at is that with so many
adjustable options across so many ports, we really need to look
into implementing something like -- and soon.  Otherwise, we're
going to end up with an unmaintainable mess, and administrators
are going to become frustrated ("how am I supposed to remember
how to build what port with what?!  Make a big sh script?"

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.                             |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060509061026.GA14039>