Re: [gentoo-dev] RFC: replacing the common-lisp-controller
Hi, On Wednesday, 18 October 2006, Matthew Kennedy wrote: > I think this scheme is more in line with our Emacs approach in > portage. This has been a popular system for those who want a > distro-maintained Emacs build but want to use their own configuration. > We install Emacs libraries to /usr/share/emacs/site-lisp and maintain > a /usr/share/site-lisp/site-gentoo.el with the Gentoo provided > initialization code. This way users are not forced to use the Gentoo > configuration -- in fact, you have to opt-in in Emacs' case by loading > /usr/share/emacs/site-lisp/site-gentoo.el from your ~/.emacs. OMG, do it yes ! I had bad and big troubles recently with clisp and it was *really8 hard to know where things happened. Thank you. -- CU Xavier -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] generic 2-clause BSD license added
Hi all, just a heads up that I added a generic 2-clause BSD license to the tree. Its name is BSD-2. The BSD license file still refers to the 3-clause BSD license. kind regards Thilo pgp5BJ932YbCp.pgp Description: PGP signature
Re: [gentoo-dev] Resurrecting "Project Dolphin"
> Hmm.. what about a minimal-media like system which could exploit unionfs > and provide similar functionality to DSL (Damn Small Linux)? I was working on livecd's a few months ago. DSL turned unionfs off by default do to buginess. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: replacing the common-lisp-controller
I'm considering replacing the common-lisp-controller system in Portage with and opt-in, asdf-binary-locations approach. The main purpose of the c-l-c is to provide a way to compile the source in /usr/share/common-lisp to a user read/writable location (currently the c-l-c uses /var/cache/common-lisp-controller/...). The c-l-c also provides a way to register and unregister Common Lisp implementations provided that each implementation comes with the c-l-c support (usually a install-clc.lisp and a driver script for installation under /usr/share/common-lisp/bin). It also provide a way to register user sources (by creating a symlink from the user's source into ~/.clc). The perceived[1] problems with the c-l-c are that it is too intrusive, makes debugging hard for upstream authors when problems arise and it is not well understood. I'm proposing that we replace the c-l-c with a light weight system based on asdf-binary-locations[2]. Each Common Lisp implementation we support would be essentially a vanilla build of upstream -- nothing saved into the Lisp image. Common Lisp library ebuilds (those that start with "cl-" in the dev-lisp category) would record the pathname where the Common Lisp system definition is installed. eg. /usr/share/common-lisp/source/cl-ppcre/ The list of pathnames would be saved in, say, /etc/asdf-source.list (one per line perhaps) and be CONFIG_PROTECT'd as usual. If the user intends to make use of the dev-lisp/cl-* ebuilds in Portage, they would include a short stub of Gentoo-provided code in thier implementation initialization file (eg. ~/.sbclrc, ~/.clisprc etc.) to add each of those recorded paths to ASDF:*CENTRAL-REGISTRY*. They would then configure and load asdf-binary-locations from their initialization file in order to direct compilation output to their user read/writable location (eg. ~/.fasls/). Natually there will be a Gentoo Guide XML document for these details. I think this scheme is more in line with our Emacs approach in portage. This has been a popular system for those who want a distro-maintained Emacs build but want to use their own configuration. We install Emacs libraries to /usr/share/emacs/site-lisp and maintain a /usr/share/site-lisp/site-gentoo.el with the Gentoo provided initialization code. This way users are not forced to use the Gentoo configuration -- in fact, you have to opt-in in Emacs' case by loading /usr/share/emacs/site-lisp/site-gentoo.el from your ~/.emacs. Footnotes: [1] from comp.lang.lisp and freenode.net #lisp [2] http://common-lisp.net/project/cl-containers/asdf-binary-locations/ -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resurrecting "Project Dolphin"
On Tue, 2006-10-17 at 22:26 -0400, Tomasz B Mloduchowski wrote: > Hmm.. what about a minimal-media like system which could exploit unionfs > and provide similar functionality to DSL (Damn Small Linux)? Feel free to submit patches to genkernel to make unionfs actually work on our releases and we'd be glad to make things work better in this regard. The truth is that currently, I'm mostly maintaining genkernel by myself, with patches from the community. I'm spending all of my "development" time with it fixing bugs. There is a re-write of genkernel in the works, but it is still in need of a bit of polish (and doesn't support 2.4 kernels, yet). > Such specialized livemedia could be useful for advanced users trying to > setup gentoo-based multimedia kiosks, demonstrations etc. Agreed. At the same time, there's catalyst and our specs already available. There's nothing stopping anyone from doing this. I haven't heard of anyone doing it, so it likely isn't as simple as just throwing the right packages on a CD. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
