Date: Tue, 9 May 2006 13:30:09 +0300 From: Sideris Michael <msid@daemons.gr> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-ports@freebsd.org Subject: Re: ports structure and improvement suggestions Message-ID: <20060509103009.GA4205@daemons.gr> In-Reply-To: <20060509061026.GA14039@pentarou.parodius.com> References: <20060508200926.GA6005@daemons.gr> <20060509061026.GA14039@pentarou.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 08, 2006 at 11:10:26PM -0700, Jeremy Chadwick wrote: > 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?" That is my point exactly. The current structure of Ports is old. The existing ways for handling ports are vague and complex. Of course if somebody wouldn't care, he would install everything the way it is. No customization. KNOBS? What is that? This is not the case though. Something has to be done to correct this chaotic situation. Additionally, you are right about using the packages. But, packages, usually are old. I mean, if you consider also this, even the packages system is not going so well. You are stuck in this situation. Use exclusively packages? Ok, but they are outdated. Use ports? Ok. Define a standard way first. Thank you for being at least a positive mind from all the answers till now. You people seem to be totally ignorant some times, honestly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060509103009.GA4205>