Date: Sat, 22 Oct 2005 09:11:06 +0300 From: Ion-Mihai Tetcu <itetcu@people.tecnik93.com> To: Vulpes Velox <v.velox@vvelox.net> Cc: Benjamin Lutz <benlutz@datacomm.ch>, nocturnal <nocturnal@swehack.se>, freebsd-ports@freebsd.org Subject: Re: Flaws in the ports system? Message-ID: <20051022091106.60a597d7@it.buh.tecnik93.com> In-Reply-To: <20051022005642.6b15e0f7@vixen42.vulpes> References: <4357D830.7060506@swehack.se> <435825F8.4020305@datacomm.ch> <20051022005642.6b15e0f7@vixen42.vulpes>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Oct 2005 00:56:42 -0500 Vulpes Velox <v.velox@vvelox.net> wrote: > On Fri, 21 Oct 2005 01:19:20 +0200 > Benjamin Lutz <benlutz@datacomm.ch> wrote: > > > nocturnal wrote: > > > This is a very low priority discussion but i was just wondering > > > if there are any known design flaws in the ports system or other > > > reasons for the ports to be replaced by a new system. > > > > They work well, more or less, and certainly as intended. There's a > > couple of things though that I think are not solved optimally: [ Support for different versions of a software package. ... ] > > - Configuration management. This is hard to get right, but I don't > > think that simply littering /usr/local/etc with .sample files is > > the best way to solve it. I've seen some infrastructure in place to > > automagically merge config file changes, but I didn't notice it > > being used so far. As it is, upgrading daemons means lots of manual > > labour (scanning the sample config file for changes, or even > > redoing the configuration from scratch), which every admin has to > > do, and which could maybe be pooled so the port maintainer does > > most of it, and the users could simply say y/n a few times in a > > tool like mergemaster. > > Interactive ports are insanely annoying. I honestly would love to see > the crap like that done away with in most cases. After I finish a few config-recursive for OPTIONS ports > projects, I am actually planning on figuring out a way rework that > in a lot nicer manner than most of the interactive stuff popping up > the damn menu is currently done. When I have the time, I plan to > solve this. What I want is this, a enviromental variable to tell it > to use the defaults, if possible, and if not to skip it. Then a BATCH=yes ? If any port which doesn't set INTERACTIVE doesn't obey it then that port needs to be fixed. > command to get a list of supported settings that that port uses. *If* all interactive ports would be using OPTIONS show-config would be enough (not counting vars that can be set by users like HOME_DIR=....) -- IOnut Unregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051022091106.60a597d7>