Remove BIND, Sendmail, Perl and etc from base?

[Garance A Drosihn]

At 8:45 PM +0200 7/24/03, Simon 'corecode' Schubert wrote:
Lately Joerg Sonnenberger told:

 > FreeBSD ports can't really be used like this, since the
 > package is installed and _afterwards_ records what 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.
I would really love to see something like this.  I have a
vague idea that openbsd has some tactic like this for their
ports system, but I'm not really sure of the details.  I
would love to be able to do "test builds and installs" of
ports, without changing anything in the actual system.  That
would make it a lot easier to test improvements to the
ports system itself.
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
extent.
I like the ability to do
   cd /usr/ports/../whatever ; make ; make install
but I do think that freebsd ports tries to shoehorn much too
much into makefile magic.
I wrote up some ideas for a somewhat different strategy for
freebsd ports, and I keep trying to get some student to
write up a proof-of-concept version of that.  Several
times I've had someone talk excitedly about implementing
what I wrote up, and then they disappear without a trace...
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, ...
What is portage?

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.
I think you should be able to, if you plan out your design
to handle that.
having e.g. python as a must-have for ports is a big deal,
however. perl is still in base, but how long?
Well, perl is gone from the base system in FreeBSD 5.

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].
I do not think that standard bourne shells are the best
way to implement this.  I've thought that the best tactic
is to take some version of ruby (my preference), strip it
down to a minimal version, rename it something different,
and use that for these kinds of things.
(I mention ruby partially because I enjoy writing in ruby,
and partially because portupgrade is written in it...).
The biggest problem with having perl in the base system,
and calling it perl, is that these system functions are
in constant conflict with running the latest-and-greatest
version of perl.  I think we can have a high-level scripting
language in the base system, as long as we do not use the
"real name" for it.  Users would still have to install the
real language from ports.
--
Garance Alistair Drosehn            =   gad at xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad at xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih at xxxxxxx