Flaws in the ports system?

[Benjamin Lutz]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20051021/b558c307/signature.bin