Date: Sat, 22 Oct 2005 00:56:42 -0500 From: Vulpes Velox <v.velox@vvelox.net> To: Benjamin Lutz <benlutz@datacomm.ch> Cc: nocturnal <nocturnal@swehack.se>, freebsd-ports@freebsd.org Subject: Re: Flaws in the ports system? Message-ID: <20051022005642.6b15e0f7@vixen42.vulpes> 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. As of now, > if there's a need to have different versions of a package in the > ports, it means creating several "top-level" ports. An example for > this is tcl: There's a lang/tcl80, lang/tcl82, lang/tcl83 and > lang/tcl84. Imo Gentoo's portage solves this better, it supports > different versions of the same port: In dev-lang/tcl I find the > following files: tcl-8.3.4.ebuild, tcl-8.4.6.ebuild, > tcl-8.4.6-r1.ebuild, tcl-8.4.9.ebuild and tcl-8.4.11.ebuild. As > far as I can tell (I'm not a portage guru, just a user) new > versions are created as a new ebuild, and old versions are > eventually dropped from the repository. This gives a "moving > window", which I think is nice. > > - 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 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 command to get a list of supported settings that that port uses. I honestly like the spaming of the sample files. If not to /usr/local/etc, then to /usr/local/share/example/etc would probally be good. I honestly feel it is the end users responsibility set it up the way they want it. Good sane defaults for the like of some servers is nice though. > - 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 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. 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 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. The other efficiency thing is > the number of files in /usr/ports now. There's *a lot* of them. > > - Searching. Personally, I strongly dislike make search because its > way too verbose. Search results easily fill several screenfuls, > and grepping it is not trivial. I've worked around this one by > creating a tool that writes grep-able sub-indexes to disk in a more > concise format, the tool's available here: > http://www.maxlor.com/freebsd-scripts.shtml > > I think that's all I can think of. Although this is a lot of text, > please remember that I was just more or less letting my thoughts > flow. I like the ports very much, and I meant in no way to > criticize or attack anyone or anyone's work in particular.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051022005642.6b15e0f7>