| From: | Simon 'corecode' Schubert <corecode@xxxxxxxxxxxx> |
| Date: | Thu, 24 Jul 2003 20:45:33 +0200 |
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 extent. 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. cheers simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News
Attachment:
pgp00003.pgp
Description: PGP signature