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>