Felix, I agree that if we consider only the essentials needed by chicken-setup, is should be possible to simplify egg installation, but this is precisely what could be accomplished by isolating the semantics in a domain-specific language.
The current chicken-setup is essentially a Scheme interpreter with some macros and procedures for compiling and installing files. There is no way, however, to separate the installation by phases, such as documentation installation, library installation, etc. You keep insisting that such support for installation phases is duplicating the functionality of package management tools, but that is not the case at all. Installation phases will help support binary packages, but would not replace their functionality. Instead of manually creating Debian and RPM packages, it would be much simpler if the egg format specified what are the make commands for compiling, and identified the different components of the egg (libraries, executables, tests, examples, documentation). The a Debian package creation tool could parse that information and generate the corresponding Debian rules and control file. I agree that dpkg and friends would probably do a better job at supporting multiple versions of the same egg, etc., so at present I don't see the need for incorporating such functionality in chicken-setup. But a domain-specific language that allows the specification of installation locations, phases, and so on, would provide a platform to experiment with such ideas in the future. -Ivan "felix winkelmann" <[EMAIL PROTECTED]> writes: > 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. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
