> > I agree about the apt-like functionality, and even proposed the > design of a domain-specific language for such purposes but Felix > thinks it makes things too complicated.
Allow me a slight rant... chicken-setup has served us well, but now has mutated into a large intricate mess. There has been a rewrite a while ago, but the messiness is still there, partly because a tool like chicken-setup has to do so many different things (file-system operations, extension handling, HTTP download, build invocation, cross-compilation, etc.). I think the only solution is to completely dump it and start from scratch. If we consider what we essentially need (executing .setup scripts in a directory with the egg sources), a backwards compatible API for executing the build scripts it should be possible to reorganize the installation and upgrading of eggs on a user's system in a simpler, better maintainable and more transparent way. I have actually tried to isolate the pure .setup API (hygienic branch, module setup-api.scm), but haven't got the time or energy to start with such a project (insert the usual *HINT* here - if someone would be willing to go for it, he/she could rely on my eternal gratefulness). I think chicken-setup should NOT duplicate functionality that modern packaging tools provide. Dpkg and portage will always do a better job at that, and it would be more worthwhile to push for adoption of eggs into these packaging systems (which, IIRC, Ivan already does with debianizing several eggs). But a simple, portable, library-only way of fetching a tarball via HTTP, extract, build and install it, upgrade it if necessary and listing what's installed would make all the extensions available to everybody (and that would be enough, IMHO). A bare minimum to have access to all those libraries and keep them up to date. cheers, felix _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
