I just packaged up SLIME into .debs. I wanted to ask for opinions on how I've packaged them.
I've packaged the slime *.el files and the swank *.lisp files into separate packages named slime-el and cl-swank respectively. My rationale is that some people such as myself may wish to install swank and slime on separate machines and use them over TCP. However separating them may make SLIME slightly more difficult to install for beginners. What do people here think?
Also, in the process of making the source friendly with debian's common-lisp-controller I had to make some changes. I edited swank.asd and put all the file components from swank-loader.lisp into it. swank-loader doesn't get used at all this way. The only other change I had to make to get this to work was using the system definition utility to start swank in slime.el instead of swank-loader. I haven't catered for ~/.swank yet but I'm sure it can easily go elsewhere.
I was wondering if my omission of swank-loader is likely to cause any complications and was also wondering what the rationale for including it was when system maintenance can be performed just by using something like ASDF or some other ubiquitous system definition utility.
Robert Marlow bobstopper@bobturf.org writes:
I just packaged up SLIME into .debs. I wanted to ask for opinions on how I've packaged them.
Great! Where/how do we check them out?
I've packaged the slime *.el files and the swank *.lisp files into separate packages named slime-el and cl-swank respectively. My rationale is that some people such as myself may wish to install swank and slime on separate machines and use them over TCP. However separating them may make SLIME slightly more difficult to install for beginners. What do people here think?
I would prefer to keep them both together.
Also, in the process of making the source friendly with debian's common-lisp-controller I had to make some changes.
sounds ominous :-)
I edited swank.asd and put all the file components from swank-loader.lisp into it. swank-loader doesn't get used at all this way. The only other change I had to make to get this to work was using the system definition utility to start swank in slime.el instead of swank-loader. I haven't catered for ~/.swank yet but I'm sure it can easily go elsewhere.
These sound generally interesting, can you post patches to the list please?
I was wondering if my omission of swank-loader is likely to cause any complications and was also wondering what the rationale for including it was when system maintenance can be performed just by using something like ASDF or some other ubiquitous system definition utility.
I can't find our original rationale in the list archive right now but I suspect it's that no system definition utility was ubiquitous at the time (october 2003). Even today I'd think that calling ASDF:OOS during startup would cause problems for quite a few people who don't have it in their image at startup.
What do people think of these requirements for slime-in-debian?:
1. Exactly the same code. If things need to change then we should do it in SLIME CVS and not in debian-specific patches.
2. Doesn't require common-lisp-controller. You should be able to 'apt-get install slime' and use it with a vanilla non-Debian Lisp.
3. We should fix some authentication on the socket connection to remove security considerations (if someone else connects to Lisp before Emacs; see top of PROBLEMS file)
Thoughts?
Hello!
This is my first post to this list, so hello all!
On Sun 20 Feb 2005 10:36, Luke Gorrie wrote:
Robert Marlow bobstopper@bobturf.org writes:
I just packaged up SLIME into .debs. I wanted to ask for opinions on how I've packaged them.
Great! Where/how do we check them out?
Actually, a Debian package was already prepared by Sean Champ [1] and it works well.
Are the 2 different packages intended to be merged and submitted for an official inclusion in Debian?
Thx, bye, Gismo / Luca
[1] http://common-lisp.net/pipermail/slime-devel/2004-September/002262.html
Luca Capello luca@pca.it writes:
Actually, a Debian package was already prepared by Sean Champ [1] and it works well.
This is very nice indeed !!!
Sean (if you're reading) can you point out how we should go forwards? I'm a Debian user but highly ignorant of the internals. I'm assuming the next thing to do is integrate the debian'ization into CVS so that we can 'make deb' or similar from a regular SLIME checkout?
Hello!
On Sun 20 Feb 2005 12:24, Luke Gorrie wrote:
Luca Capello luca@pca.it writes:
Actually, a Debian package was already prepared by Sean Champ [1] and it works well.
This is very nice indeed !!!
Sean (if you're reading) can you point out how we should go forwards? I'm a Debian user but highly ignorant of the internals. I'm assuming the next thing to do is integrate the debian'ization into CVS so that we can 'make deb' or similar from a regular SLIME checkout?
Actaully, if the Debian folder is going to be integrated into the CVS, you don't need to use a 'make deb' instruction, but just a "normal" 'dpkg-buildpackage'.
OTOH, if CVS sources can produce Debian native packages (which means that they have a debian/ folder), you can use other Debian tools like 'cvs-buildpackage' ('apt-cache show cvs-buildpackage' or [1]).
Thx, bye, Gismo / Luca
PS, Sean, if you still need help to make your package enter Debian, please contact me in private, I'm in the process of being sponsored for another package (cl-s-xml [2]), so I can give you some hints ;-)
[1] http://packages.debian.org/unstable/devel/cvs-buildpackage [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292643
On Sun, 2005-02-20 at 11:07 +0100, Luca Capello wrote:
Actually, a Debian package was already prepared by Sean Champ [1] and it works well.
Yeah, I asked on #lisp whether it had been done and was told it hadn't. It wasn't until I went to update cliki's SLIME page to announce the availability of my .debs that I noticed it had indeed been done :(
Are the 2 different packages intended to be merged and submitted for an official inclusion in Debian?
Yeah, getting it into Debian is the plan. I'm sure there's a lot of people here other than myself who have been waiting for it to get into Debian for a long time now :)
Hello Robert!
On Sun 20 Feb 2005 17:10, Robert Marlow wrote:
On Sun, 2005-02-20 at 11:07 +0100, Luca Capello wrote:
Actually, a Debian package was already prepared by Sean Champ [1] and it works well.
Yeah, I asked on #lisp whether it had been done and was told it hadn't. It wasn't until I went to update cliki's SLIME page to announce the availability of my .debs that I noticed it had indeed been done :(
It's not real a problem, I found the SLIME Debian package by Google and digging in the slime-devel mailing-list ;-)
Are the 2 different packages intended to be merged and submitted for an official inclusion in Debian?
Yeah, getting it into Debian is the plan. I'm sure there's a lot of people here other than myself who have been waiting for it to get into Debian for a long time now :)
You're right: the RFP is dated back in Sep 17th, 2004 [1]. You should continue in that way (I mean, announcing your ITP on that bug and so on [2]). But as you posted that KMR is helping you, you're safe ;-)
Thx, bye, Gismo / Luca
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272098 [2] http://www.debian.org/devel/wnpp/#l3
Luca Capello luca@pca.it writes:
Actually, a Debian package was already prepared by Sean Champ [1] and it works well.
I'm having one issue. I've installed the debian package but I want to actually run slime from CVS. I think it should be enough to just put the CVS slime first in my load-path before loading, but this part of the debian init is causing me trouble:
(setq slime-backend "/usr/share/common-lisp/source/slime/swank-loader.lisp")
Normally the CL code is found relative to the Elisp, but if you install the debian package then it sets an absolute path to the package-installed Lisp code.
I understand that something like this is needed for the debian package to install the CL files in a different directory to the Elisp and still be able to find it. I wonder if there's a nice fix to keep this file layout but also allow a newer SLIME to "shadow" the debian one via the load-path?
On Sun, 2005-02-20 at 10:36 +0100, Luke Gorrie wrote:
Robert Marlow bobstopper@bobturf.org writes:
I just packaged up SLIME into .debs. I wanted to ask for opinions on how I've packaged them.
Great! Where/how do we check them out?
Currently at http://www.bobturf.org/software/slime/ I'm working with KMR to get it into Debian.
I've packaged the slime *.el files and the swank *.lisp files into separate packages named slime-el and cl-swank respectively. My rationale is that some people such as myself may wish to install swank and slime on separate machines and use them over TCP. However separating them may make SLIME slightly more difficult to install for beginners. What do people here think?
I would prefer to keep them both together.
So chuck them back together then? Or should we ask for other users' opinions?
Also, in the process of making the source friendly with debian's common-lisp-controller I had to make some changes.
sounds ominous :-)
I edited swank.asd and put all the file components from swank-loader.lisp into it. swank-loader doesn't get used at all this way. The only other change I had to make to get this to work was using the system definition utility to start swank in slime.el instead of swank-loader. I haven't catered for ~/.swank yet but I'm sure it can easily go elsewhere.
These sound generally interesting, can you post patches to the list please?
Attached
I was wondering if my omission of swank-loader is likely to cause any complications and was also wondering what the rationale for including it was when system maintenance can be performed just by using something like ASDF or some other ubiquitous system definition utility.
I can't find our original rationale in the list archive right now but I suspect it's that no system definition utility was ubiquitous at the time (october 2003). Even today I'd think that calling ASDF:OOS during startup would cause problems for quite a few people who don't have it in their image at startup.
What do people think of these requirements for slime-in-debian?:
Exactly the same code. If things need to change then we should do it in SLIME CVS and not in debian-specific patches.
Doesn't require common-lisp-controller. You should be able to 'apt-get install slime' and use it with a vanilla non-Debian Lisp.
We should fix some authentication on the socket connection to remove security considerations (if someone else connects to Lisp before Emacs; see top of PROBLEMS file)
Thoughts?
I'm all for 1. One of the reasons I wanted to approach the list was to see if perhaps we could find a way to make both solutions work depending on the environment under which SLIME is being installed.
I find Common-lisp-controller makes it very conveniant to install and uninstall lisp packages under Debian. It solves many of the problems surrounding different implementations and different architectures all using the same source directory over NFS that I understand swank-loader is intended to solve and, more importantly, it does it in a way that's consistent with the rest of Debian's lisp packages. I'm by no means pushing the idea of doing away with swank-loader, but perhaps if we could arrange for ASDF to be used by default, and if it doesn't exist, fall back on swank-loader? Probably something simple like #+asdf (asdf:oos 'asdf:load-op :swank) #-asdf (load "swank-loader.lisp") is all that's needed.
Calling swank.asd seems to imply asdf is installed so it's probably ok if it doesn't load swank-loader at all.
Good point on 3. The Debian security team may complain about that :) I think this could be fixed by generating something random with M-x SLIME and using it as a key for create-server. I can whack that together and submit a patch if that's all that's required.
Robert Marlow writes:
On Sun, 2005-02-20 at 10:36 +0100, Luke Gorrie wrote:
- We should fix some authentication on the socket connection to remove security considerations (if someone else connects to Lisp before Emacs; see top of PROBLEMS file)
Thoughts?
Good point on 3. The Debian security team may complain about that :) I think this could be fixed by generating something random with M-x SLIME and using it as a key for create-server. I can whack that together and submit a patch if that's all that's required.
I think this would be sufficient to solve the big gaping security hole, and is probably the best portable solution. What would be even nicer would be additional support for Unix-domain sockets. If create-server could be passed a pathname specifier, or even an existing socket, it would make administrative access to Lisp servers nicer. Eg, I have a server running an SBCL image that's running both Araneida and SWANK. It would be nice if SWANK listened on a socket that only users in the webadmin group could connect to, instead of the ugly ugly hack I have now.
-
Luca Capello -
Luke Gorrie -
Robert Marlow -
Thomas F. Burdick