Date: Sat, 22 Oct 2005 08:59:54 +0300 From: Ion-Mihai Tetcu <itetcu@people.tecnik93.com> To: Benjamin Lutz <benlutz@datacomm.ch> Cc: nocturnal <nocturnal@swehack.se>, freebsd-ports@freebsd.org Subject: Re: Flaws in the ports system? Message-ID: <20051022085954.5ef9d2ff@it.buh.tecnik93.com> In-Reply-To: <435825F8.4020305@datacomm.ch> References: <4357D830.7060506@swehack.se> <435825F8.4020305@datacomm.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Without support from upstream (a nice example is postfix) fully automating this is nearly impossible. More, the way the things are in this regard might be good as it forces the sysadmin to read (and supposedly understand :) the changes in the new version. > - Mirror selection. For us europeans, the US sourceforge mirror which > is used by a lot of ports by default is very slow. It is possible to Work is being done in this area. Perhaps the biggest problem for finding the fastest mirror for each distfile is that you have to relay on things outside the ports system and because of this any sollution isn't likely to be included in the *.mk's > override the mirror selection by setting some variables in > make.conf, but it's far from apparent how to do so, or that it is > even possible. Please submit a patch for Handbook / ports(7) / .... > Additionally, while fetch seems to have some support > for resuming interrupted downloads, often enough a partial or > corrupted existing distfile leads to fetch doing nothing at all. The > solution is easy, just delete the existing distfile, but the tools > don't hint at that. > > - Speed. The ports use of makefiles as prime mechanism makes it very > flexible, but given the sheer number of ports we have by now, it's > also become slow. Building an INDEX takes forever, and pkg_version > is painful to use on slow machines. A result of that is that we now > have a number of add-on tools that speed up things with binary dbs > and caches, however I consider those a work-around, not a solution. > Basically, I think that the current system doesn't scale too well. > One possibility I can think of that alleviates the problem a bit > without changing the existing structure (there's this POLA thing I > guess) is changing make(1) so it recurses inside the same process, > instead of launching a new process for every submakefile (or maybe > it already does that? I don't know). Another possibility would be There has been some work in this area and the seed has substantially increase in the last 2 years, but of course there's space for more. The work however is far from being trivial. > making it possible to determine some static configuration, say, a > ports version number, quicker, without having to call make (I > realize that with things like slave ports, even a version number is > not that static. Maybe there could be a fallback for those cases?). > Another possibility would be moving to a binary DB right away, > relying on tools to extract the information. This would make cvsup > difficult though. No, thank you. Personally I don't like spending time around windows registry. -- 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?20051022085954.5ef9d2ff>