Date: Fri, 21 Oct 2005 01:19:20 +0200 From: Benjamin Lutz <benlutz@datacomm.ch> To: nocturnal <nocturnal@swehack.se> Cc: freebsd-ports@freebsd.org Subject: Re: Flaws in the ports system? Message-ID: <435825F8.4020305@datacomm.ch> In-Reply-To: <4357D830.7060506@swehack.se> References: <4357D830.7060506@swehack.se>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig86718D3B4871B1D6B96C0D35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. - 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. Cheers Benjamin --------------enig86718D3B4871B1D6B96C0D35 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDWCX8gShs4qbRdeQRArRXAJ9LNyRUsQ//61ME0Y+8oo8qxeCZCwCgg+0r 4fxtXo429fgLI/2D6nh9G/c= =EhW0 -----END PGP SIGNATURE----- --------------enig86718D3B4871B1D6B96C0D35--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?435825F8.4020305>