Flaws in the ports system?
benlutz at datacomm.ch
Thu Oct 20 16:19:31 PDT 2005
> 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
- 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:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20051021/b558c307/signature.bin
More information about the freebsd-ports