Remove BIND, Sendmail, Perl and etc from base?

Simon 'corecode' Schubert corecode at
Thu Jul 24 11:45:33 PDT 2003

Lately Joerg Sonnenberger told:

> > Ports can be used this way (make package), but few take advantage of
> > it,
> FreeBSD ports can't really be used like this, since the package is
> installed and _afterwards_ recorded is installed. If the plist is
> wrong, you end up having dead files on your system.

well, a transparent file system layer can really solve lots of hazzle...
portage guys do this with an LD_PRELOAD lib or something like that which
forces the packages to be built *and* installed into a fake root
filesystem and then records installed files and after that copies these
files into the real file system. pretty slick.

furthermore, i really dislike the idea of using make(1) for ports. there
is just a lot of hazzle because you can't set variables on runtime, have
to escape shell command constructs a very ugly way and stuff like that.
the real purpose of make (dependancy stuff) is used to a very limited

i'd vote for another system, one that is more current than makefiles. i
don't say these strange python/shell/whatever structs of portage are the
way to go, but first of all one big decision has to be made:

should the packaging system be completely contained in the base system?
i don't think this is a good solution. see freebsd's mess: pkg_add is in
base, so you can't dynamically change the packaging format because of
legacy users.
having e.g. python as a must-have for ports is a big deal, however. perl
is still in base, but how long?

pure shell scripts do the job very well too. (portage's ebuilds are
nothing but bash scripts). use default shell functions etc and you're
done VERY cheap. and shell is always there[tm].

just some thoughts.


\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: PGP signature"
URL: <>

More information about the Kernel mailing list