On Fri, Jul 11, 2008 at 2:42 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > 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.
If you say "the egg format specified", what do you mean exactly? The .meta file, or a separate entity? > > > 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. > Ok, I understand. And I do not oppose a higher-level approach to describing an egg's contents (for example by using a DSL). But I still would like to simplify it as much as possible (rather provide the option to use the functionlity of egg setting-up as a library, and so giving the user full control, instead of trying to write the perfect package management system). Additionally there is no way of breaking backwards-compatibility with existing .setup scripts. The transition to modules will be hard enough and a new chicken-setup could provide a high-level interface for new eggs plus a API for old ones. cheers, felix _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
