Dear all,
With the recent discussions about community, it seems an apposite time
to announce the formation of the comprehensive Common Lisp archive
network, and request contributions for same.
The goal is to facilitate the distribution of Lisp software (and
attendant utilities) in an integrated manner, much as CTAN[1] does for
(La)TeX or CPAN[2] for perl. In short, that the user be able to type
a single command to download, compile and install a module or
application, including all the libraries that it depends on. We are
presently targetting Unix-like operating systems, though non-Unix
expertise is welcome.
The prototype implementation does not yet embody the concept in all
its glory. The prototype is currently 25 or so packages for Debian's
`unstable/testing' Linux distribution, initially available on i386 and
Alpha platforms, and from a single host.
If you have root access on a Debian `unstable/testing' machine, then the
addition of the lines
--- cut here ---
deb http://www-jcsu.jesus.cam.ac.uk/ftp/pub/debian local lisp
deb-src http://www-jcsu.jesus.cam.ac.uk/ftp/pub/debian local lisp
--- cut here ---
to your /etc/apt/sources.list, followed by the usual apt-get
incantations, will allow you to download the packages; alternatively,
the packages may be directly downloaded from
<URL:http://www-jcsu.jesus.cam.ac.uk/ftp/pub/debian/lisp/>.
A proof-of-concept experiment has been conducted with a RedHat system;
for now, instructions and files may be found at
<URL:http://www-jcsu.jesus.cam.ac.uk/ftp/pub/redhat/lisp/>; this should
be fairly applicable to other RPM-based systems.
* Currently, packages of note include
- ILISP
- various bits of CLOCC[5]
- onShore's[6] IMHO and UncommonSQL, and various helper packages
Packaging software is not particularly hard, just fiddly. Volunteers
are welcome.
* What do we need?
1) Help porting the packages to other packaging systems. The Debian
infrastructure works as follows: the systems follow the
common-lisp-controller[3] policy with respect to their file placement
(essentially, the Lisp implementations have translations for the
logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
post-installation script in the packages arranges for the compilation
of the package for every relevant Lisp implementation. Advice on the
best layout for non-Debian systems would also be welcome.
2) We have a problem currently with CLISP[4] in that its
implementation of pathnames is not sufficiently close to the ANSI
specification to work with common-lisp-controller. We'd love to have
CLISP support in cCLan, but need assistance from clisp hackers to make
it happen. Support for other commercial or free implementations would
also be most welcome.
3) Aside from this - more code. Of course, software of this kind is
generally written to service a need rather than out of the goodness of
one's own heart, but should people be willing to contribute they would
be most welcome.
4) N is for "Network": we have an offer of a second site at
ftp.linux.org.uk, and plan to use rsync servers to keep things
consistent between them. If you run an FTP server and would like to
provide another mirror - especially if your user community is not
network-local to either of the existing sites, please contact us.
* How can you get in touch?
This effort has sprung forth from CLiki and the people on the #lisp
OpenProjects IRC channel[7]. The best way to leave a message is to
edit the cliki cCLan page[8], or to show up on IRC. We expect also to
set up a mailing list in the very near future, the formation of which
will be trailed here.
Thank you,
Christophe et al
[1] http://www.tex.ac.uk/
[2] http://www.cpan.org/
[3] http://ww.telent.net/cliki/common-lisp-controller
[4] http://clisp.sourceforge.net/
[5] http://clocc.sourceforge.net/
[6] http://alpha.onshored.com/lisp-software/
[7] http://ww.telent.net/cliki/IRC
[8] http://ww.telent.net/cliki/cclan
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
> * In message <··············@lambda.jesus.cam.ac.uk>
> * On the subject of "prototype `comprehensive' CL archive `network'"
> * Sent on 01 Jun 2001 16:30:05 +0100
> * Honorable Christophe Rhodes <·····@cam.ac.uk> writes:
>
> With the recent discussions about community, it seems an apposite time
> to announce the formation of the comprehensive Common Lisp archive
> network, and request contributions for same.
I thought CLOCC was supposed to be it :-)
(the original name I made up for CLOCC was, indeed, CLAN, but it was
rejected because the word "clan" has certain unsavory connotations).
why don't you turn CLOCC into what you want?
> 2) We have a problem currently with CLISP[4] in that its
> implementation of pathnames is not sufficiently close to the ANSI
> specification to work with common-lisp-controller.
I am not aware of any problems.
I fixed all the bugs you reported.
If you have any new bugs, please report them on SF.
> [4] http://clisp.sourceforge.net/
the correct URL is http://clisp.cons.org
--
Sam Steingold (http://www.podval.org/~sds)
I'm out of my mind, but feel free to leave a message...
Sam Steingold <···@gnu.org> writes:
> > With the recent discussions about community, it seems an apposite time
> > to announce the formation of the comprehensive Common Lisp archive
> > network, and request contributions for same.
>
> I thought CLOCC was supposed to be it :-)
That's almost an FAQ, but not quite. Nobody's got as far as writing
up the FAQ list anyway yet.
It's not apparent just from the names, but there are sufficient
differences between CLOCC and CCLAN that the two projects are pretty
distinct.
CLOCC is a single CVS repository; people can check it out and work on
bits. Anyone can check things out from it, but it's a tool mostly
intended for developers - you have to set up pathnames yourself,
decide where you want to keep stuff, and manage your own dependencies,
etc etc. And if you want your stuff to be available there, you need
to use the sourceforge cvs server.
CCLAN is a collection of standalone packages drawn from all over the
net. The emphasis is on "packages". CCLAN is not a repository for
package developers, it's a place for developers to put their
libraries/applications when they've decided they're stable and want to
release them to the rest of the world. It's for end-users. To get it
to that point we need to introduce policy - things like "must have a
system definition, must use this lpn struture, should have a manual
page, should subdivide the package namespace in some way (jury's
still out on that; I favour kmp's proposal), should add to *features*
if it's a library" and so on, which is not necessarily appropriate for
the more flexible behaviours that developers need.
CLOCC packages could well go into CCLAN - some parts of it have.
So could a host of other packages from other people, and some of them
have, too.
> (the original name I made up for CLOCC was, indeed, CLAN, but it was
> rejected because the word "clan" has certain unsavory connotations).
Yes, I quite agree (also note that all the clan.* domain names are
gone). Hence we have 'CCLAN' (some people say cCLan) not 'clan'.
> why don't you turn CLOCC into what you want?
Because it's doing a very good job at being what it is already.
> > 2) We have a problem currently with CLISP[4] in that its
>
> I am not aware of any problems.
> I fixed all the bugs you reported.
That's cool! Does common-lisp-controller work with it now, then?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
[ I tried to reply to this last night, but it would appear that my
news server ate the followup (unless I pressed the wrong key, of
course...]
Sam Steingold <···@gnu.org> writes:
> > * Honorable Christophe Rhodes <·····@cam.ac.uk> writes:
> >
> > With the recent discussions about community, it seems an apposite time
> > to announce the formation of the comprehensive Common Lisp archive
> > network, and request contributions for same.
>
> I thought CLOCC was supposed to be it :-)
> (the original name I made up for CLOCC was, indeed, CLAN, but it was
> rejected because the word "clan" has certain unsavory connotations).
>
> why don't you turn CLOCC into what you want?
Dan Barlow has addressed some of this; another part is that CLOCC's
charter (from http://clocc.sourceforge.net/) says that CLOCC code
should be "free" (which would rule out, say, cl-http packages) and
"portable" (which would rule out some FFI bindings packages, such as
clg or db-sockets).
In other words, I think the aims are different. The other important
distinction, which I know Dan has already mentioned but I think bears
repeating, is that cCLan packages have a certain amount of policy
attached, which is what makes it possible to make them convenient for
the user, so that things `just work'. I suspect that this would not be
a good thing for CLOCC to have to enforce, particularly since this is
the prototype stage and things might have to change.
> > 2) We have a problem currently with CLISP[4] in that its
> > implementation of pathnames is not sufficiently close to the ANSI
> > specification to work with common-lisp-controller.
>
> I am not aware of any problems.
> I fixed all the bugs you reported.
> If you have any new bugs, please report them on SF.
I acknowledge the speedy response time. I do actually have a new bug,
which I will report when I get back to speedy-net-access-ville (unless
it's fixed in the meantime, of course).
> > [4] http://clisp.sourceforge.net/
> the correct URL is http://clisp.cons.org
Thanks for the correction.
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes wrote:
> Dear all,
>
> With the recent discussions about community, it seems an apposite time
> to announce the formation of the comprehensive Common Lisp archive
> network, and request contributions for same.
>
> The goal is to facilitate the distribution of Lisp software (and
> attendant utilities) in an integrated manner, much as CTAN[1] does for
> (La)TeX or CPAN[2] for perl. In short, that the user be able to type
> a single command to download, compile and install a module or
> application, including all the libraries that it depends on. We are
> presently targetting Unix-like operating systems, though non-Unix
> expertise is welcome.
The problem here is maybe that most users of free Lisp-Systems seem to
use Unix-Like OSes. So it would be important now that the users of other
OSes (Windows, Mac...) contribute their sight of the things as soon as
possible.
> * What do we need?
...
> 4) N is for "Network": we have an offer of a second site at
> ftp.linux.org.uk, and plan to use rsync servers to keep things
> consistent between them. If you run an FTP server and would like to
> provide another mirror - especially if your user community is not
> network-local to either of the existing sites, please contact us.
Maybe someone knows the MOGUL project for the Mozart/Oz programming system.
There they have (maybe several?) servers that only contain some kind of
"directory service". Each available package is there documented in what it
does and what it needs. But the packages are not available there by itself
- instead of this there are direct links to the packages on the sites of
the maintainers of the different packages. This leads to a rather decentral
system. I know that much of this functionality is handled already by
sophisticated packaging systems like Debian but not every Lisp user has the
luck of having this tools. This does _not_ mean that we should not use
Debian or RPM but only that the locating of a Package and the resolving of
dependencies should IMHO be independent from specific package-systems.
Regards,
Jochen
From: David E. Young
Subject: Re: prototype `comprehensive' CL archive `network'
Date:
Message-ID: <3B182C04.8004A47A@computer.org>
Christophe Rhodes wrote:
> The goal is to facilitate the distribution of Lisp software... In short, that
> the user be able to type a single command to download, compile and install a
> module or application, including all the libraries that it depends on...
I think this is a splendid idea. LISA (http://lisa.sourceforge.net) includes a
copy of CLOCC's PORT module as a convenience, and because LISA depends on it.
Being able to download PORT "automatically" during a build, allowing me to
remove PORT from the LISA distribution proper, would eliminate the replication
inherent with this approach.
I'll take a closer look at your work.
Regards,
--
-----------------------------------------------------------------
David E. Young
········@computer.org (defun real-language? (lang)
http://lisa.sourceforge.net (eq lang 'LISP))
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
"David E. Young" <········@computer.org> writes:
> Christophe Rhodes wrote:
> > The goal is to facilitate the distribution of Lisp software... In
> > short, that the user be able to type a single command to download,
> > compile and install a module or application, including all the
> > libraries that it depends on...
> I think this is a splendid idea.
Oh good :-)
> LISA (http://lisa.sourceforge.net) includes a copy of CLOCC's PORT
> module as a convenience, and because LISA depends on it. Being able
> to download PORT "automatically" during a build, allowing me to
> remove PORT from the LISA distribution proper, would eliminate the
> replication inherent with this approach.
Indeed. Since we're currently using .deb packages, dependency tracking
is fairly easy, and apt deals with the necessary downloading of files.
I've cast a brief glance at LISA; to package it in the current
framework should be relatively straightforward. You'd need a
lisa.system file that contains
(mk:defsystem lisa
...
:depends-on (clocc-port)
...)
[ with some logical-pathname changes from your current defsys.lisp,
too -- essentially, source files live in "cl-library:lisa;**;*.lisp" ]
and in the debian/control file, you can just have
Depends[1]: clocc-port
Then, on apt-get install lisa, clocc-port should be installed and
configured if it isn't already.
While this is great for those of us running Debian, we do recognize
that not everyone does, and although apt has reportedly been ported to
RPM based systems not everyone uses Linux either. But this I hope
gives you some idea of the possibilities...
Cheers,
Christophe
[1] Possibly Pre-Depends. I'm not entirely sure what is guaranteed.
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Great!
Christophe Rhodes <·····@cam.ac.uk> wrote:
: 1) Help porting the packages to other packaging systems. The Debian
: infrastructure works as follows: the systems follow the
: common-lisp-controller[3] policy with respect to their file placement
: (essentially, the Lisp implementations have translations for the
: logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
: post-installation script in the packages arranges for the compilation
: of the package for every relevant Lisp implementation. Advice on the
: best layout for non-Debian systems would also be welcome.
No advice, just a note that it was a major headache to convert the
cmucl deb to rpm on suse_7.0 with the perl based alian package (which
didn't change since).
debian dpck also requires GLIBC 2.2 which I haven't dared to install yet.
(SUSE 7.1 changed to that)
It works, but only with manual fixes, not fully automatic as it should.
I would really appreciate pre-packaged RPM's (for SUSE in my case, don't
know for redhat)
layout:
debian uses now the /usr pefix, which I didn't dare to mix up with
local /usr/local prefix policy.
current /usr/src/cmucl/cmucl/src seems also be odd.
/usr/local/lib/cclan/... seems to be fine.
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
Reini Urban <······@x-ray.at> writes:
> debian dpck also requires GLIBC 2.2 which I haven't dared to install yet.
> (SUSE 7.1 changed to that)
If you mean dpkg, then the version included in the stable release of
Debian most certainly only requires glibc 2.1, since stable
(i.e. potato, i.e. Debian 2.2) itself only includes glibc 2.1.7.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Reini Urban <······@x-ray.at> writes:
> Great!
>
> Christophe Rhodes <·····@cam.ac.uk> wrote:
> : 1) Help porting the packages to other packaging systems. The Debian
> : infrastructure works as follows: the systems follow the
> : common-lisp-controller[3] policy with respect to their file placement
> : (essentially, the Lisp implementations have translations for the
> : logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
> : post-installation script in the packages arranges for the compilation
> : of the package for every relevant Lisp implementation. Advice on the
> : best layout for non-Debian systems would also be welcome.
>
> No advice, just a note that it was a major headache to convert the
> cmucl deb to rpm on suse_7.0 with the perl based alian package (which
> didn't change since).
> debian dpck also requires GLIBC 2.2 which I haven't dared to install yet.
> (SUSE 7.1 changed to that)
>
> It works, but only with manual fixes, not fully automatic as it should.
> I would really appreciate pre-packaged RPM's (for SUSE in my case, don't
> know for redhat)
Have you looked at
<URL:http://www-jcsu.jesus.cam.ac.uk/ftp/pub/redhat/lisp>
and
<URL:http://www-jcsu.jesus.cam.ac.uk/ftp/pub/redhat/lisp/README>?
Currently, that's the best I've been able to do (think of it as a
taster :-); I hope that those instructions make sense. You wouldn't in
that case need the debian cmucl packages alienized, if you have your
own cmucl/sbcl/whatever installed.
In terms of providing a cmucl rpm, there are either Miles Egan's or
some mentioned on CLiki...
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> 1) Help porting the packages to other packaging systems. The Debian
> infrastructure works as follows: the systems follow the
> common-lisp-controller[3] policy with respect to their file placement
> (essentially, the Lisp implementations have translations for the
> logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
> post-installation script in the packages arranges for the compilation
> of the package for every relevant Lisp implementation. Advice on the
> best layout for non-Debian systems would also be welcome.
Have you considered following perl's module and developing a system
that doesn't depend on a specfic packaging system and leaving
deb/rpm-like packaging as a separate problem? I like being able to
install a new perl module without first having to get it to cooperate
with the local packaging system. FreeBSD, Debian, and Redhat all seem
to be able to wrap CPAN-modules in their own packaging systems without
too much trouble.
--
miles egan
unix system administrator
·····@pixar.com
Miles Egan <·····@puzl.pixar.com> writes:
...
> Have you considered following perl's module and developing a system
> that doesn't depend on a specfic packaging system and leaving
> deb/rpm-like packaging as a separate problem? I like being able to
> install a new perl module without first having to get it to cooperate
> with the local packaging system. FreeBSD, Debian, and Redhat all seem
> to be able to wrap CPAN-modules in their own packaging systems without
> too much trouble.
Somehow (given my recent mishaps with RPM) I think this option should
be left open.
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Miles Egan <·····@puzl.pixar.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > 1) Help porting the packages to other packaging systems. The Debian
> > infrastructure works as follows: the systems follow the
> > common-lisp-controller[3] policy with respect to their file placement
> > (essentially, the Lisp implementations have translations for the
> > logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
> > post-installation script in the packages arranges for the compilation
> > of the package for every relevant Lisp implementation. Advice on the
> > best layout for non-Debian systems would also be welcome.
>
> Have you considered following perl's module and developing a system
> that doesn't depend on a specfic packaging system and leaving
> deb/rpm-like packaging as a separate problem?
Oh, yes. The reason (well, I think) that we're currently using .debs
is that it's terribly convenient for those who have Debian, as using
debs solves the automatic download and dependency problems for us.
A more Operating Sytem/Environment-agnostic system is definitely on
the cards, though I strongly suspect a prototype will be developed by
someone who doesn't use Debian, and so is looking enviously in...
I believe someone mentioned something about starting to deal with
this on IRC, but please don't let this stop anyone from
designing/coding :-)
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Miles Egan wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> 1) Help porting the packages to other packaging systems. The Debian
>> infrastructure works as follows: the systems follow the
>> common-lisp-controller[3] policy with respect to their file placement
>> (essentially, the Lisp implementations have translations for the
>> logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
>> post-installation script in the packages arranges for the compilation
>> of the package for every relevant Lisp implementation. Advice on the
>> best layout for non-Debian systems would also be welcome.
>
> Have you considered following perl's module and developing a system
> that doesn't depend on a specfic packaging system and leaving
> deb/rpm-like packaging as a separate problem? I like being able to
> install a new perl module without first having to get it to cooperate
> with the local packaging system. FreeBSD, Debian, and Redhat all seem
> to be able to wrap CPAN-modules in their own packaging systems without
> too much trouble.
Yes it would be nice if the cCLan modules dependency tracking and other info
are handled package-system independend. At the best building a RPM or DEB
out of a cCLan package should be a simple wrapper. A while ago I discussed
this with some others but was not able to make my point clear. I personally
would prefer to use as much Lisp for the package-managing process as
possible. I would tolerate some quirks related to cross-lisp-system
portability if we then could be more independend of package-systems like
RPM or DEBs (which does not even exist on some platforms).
Regards,
Jochen
Miles Egan <·····@puzl.pixar.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > 1) Help porting the packages to other packaging systems. The Debian
> > infrastructure works as follows: the systems follow the
> > common-lisp-controller[3] policy with respect to their file placement
> > (essentially, the Lisp implementations have translations for the
> > logical hosts "CL-LIBRARY" and "CL-SYSTEMS"); then the
> > post-installation script in the packages arranges for the compilation
> > of the package for every relevant Lisp implementation. Advice on the
> > best layout for non-Debian systems would also be welcome.
>
> Have you considered following perl's module and developing a system
> that doesn't depend on a specfic packaging system and leaving
> deb/rpm-like packaging as a separate problem? I like being able to
> install a new perl module without first having to get it to cooperate
> with the local packaging system. FreeBSD, Debian, and Redhat all seem
> to be able to wrap CPAN-modules in their own packaging systems without
> too much trouble.
I am not familiar with PERL "module" conventions (of CPAN conventions)
could anybody summarize them here (saving me time :) )
Thanks
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I am not familiar with PERL "module" conventions (of CPAN conventions)
> could anybody summarize them here (saving me time :) )
A Perl module as downloaded from CPAN is a tar.gz file that unpacks
into its own directory - typically the module Foo::Bar is called
Foo-Bar-0.81 or something. Having unpacked it you run perl
Makefile.PL ; make ; make test ; make install and it installs itself
where perl can find it and its documentation where perldoc can find
it.
To the best of my knowledge, there's no automated uninstall facility;
someone please correct me if I'm wrong there.
There also is an interactive application (also called CPAN) which you
can run from the shell, which will search for modules in the CPAN
archive and download and install them normally - either system-wide
(if you run it as root) or in the user's personal path.
There may be more to it than that, but its mostly details rather than
user-visible functionality. Yes, we could do the same as far as
package format goes, and yes, we probably will. The proposed CCLAN
Host Standard specifies most of the stuff needed to get this to work.
I (personal opinion) am not so convinced that the CPAN _application_
is useful, because it doesn't play nice with the platform package
system and I'd rather use something that did. Automatic package
download is something that several projects have or are working on
currently (apt, red carpet, autorpm, the Eazel thing whatever it was
called) and I don't think I'm motivated to create another just for the
sake of being able to say that I did it in Lisp. I'd rather have a
bunch of scripts to convert cclan packages into platform packages and
let the platform deal with it.
But don't let me stop you if you want to ;-). It would be useful for
people using systems that aren't the focus of mainstream
free-software-packaging projects.
-dan, we're taking patches
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> To the best of my knowledge, there's no automated uninstall facility;
> someone please correct me if I'm wrong there.
>
> There also is an interactive application (also called CPAN) which you
> can run from the shell, which will search for modules in the CPAN
> archive and download and install them normally - either system-wide
> (if you run it as root) or in the user's personal path.
>
> There may be more to it than that, but its mostly details rather than
> user-visible functionality. Yes, we could do the same as far as
> package format goes, and yes, we probably will. The proposed CCLAN
> Host Standard specifies most of the stuff needed to get this to work.
One interesting thing that the CPAN application does is dependency
management. If you tell it to install module Foo, it will also fetch
and install everything that Foo needs and that is not present on your
system. Since Perl packages its functionality fairly fine-grained,
doing this manually has the feeling of doing a depth first tree walk.
--
Lieven Marchand <···@wyrd.be>
Making laws appears to win votes. Enforcing them doesn't.
See Rule One. Roger Burton West in the monastery.
Lieven Marchand <···@wyrd.be> writes:
> One interesting thing that the CPAN application does is dependency
> management. If you tell it to install module Foo, it will also fetch
> and install everything that Foo needs and that is not present on your
> system. Since Perl packages its functionality fairly fine-grained,
> doing this manually has the feeling of doing a depth first tree walk.
Yup. So does Debian apt-get for its packages, and at least one of the
available Red Hat package updaters.
The shared library dependencies for Gnome packages have long passed
the point that it would be remotely sane to install by them by hand
unless you just install absolutely everything all at once.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > I am not familiar with PERL "module" conventions (of CPAN conventions)
> > could anybody summarize them here (saving me time :) )
>
> A Perl module as downloaded from CPAN is a tar.gz file that unpacks
> into its own directory - typically the module Foo::Bar is called
> Foo-Bar-0.81 or something. Having unpacked it you run perl
> Makefile.PL ; make ; make test ; make install and it installs itself
> where perl can find it and its documentation where perldoc can find
> it.
I'd say "perl Makefile.PL;make" corresponds fairly well to what
mk:defsystem can do. Thus, I'd say the logical packaging scheme for
cclan would be a tarball with a <packagename>.system file inside. A
cclan client would then download the tarball, unpack it and do
(operate-on-system <packagename> ...)
"make test" would correspond to having a "test.lisp" inside the
tarball that would be loaded after the package was compiled.
"make install" would require that anyone who wished to fully automate
the use of the cclan system defined a logical directory into which a
cclan client app could copy the compiled files/docs. All packages
could be required to provide a list of files to install
(documentation, binaries).
So my preferred setup would be something like this:
To be a well-behaved cclan citizen a package must meet the following
criteria:
A) It must be a tarball containing only one directory and no files
at the top-level.[1]
B) The tarball must contain _one_ file in the top-level directory
whose name ends with .system. This file will be used by
mk:defsystem. [2]
C) The tarball must contain a file "test.lisp" in the top-level
directory which must define a function "packagename:test". If
this function evaluates non-nil after calling (operate-on-system
"packagename" :compile), the build will be considered to have
failed, and installation will halt.
D) The tarball must contain a file "install.lisp" in the top-level
directory which defines:
+) *packagename-docs* wich is a list of files or directories that
belong in a documentation directory.[3]
+) *packagename-binaries* which is a list of binaries (without
extension) that belong in a library directory.
A cclan client programs could then automatically call
(operate-on-system ...) and then copy the resulting files into
"docs:packagename/" and "lib:packagename/".
The perl CPAN (packages and client) elaborate on all theese with
things like a standard format for the output of the tests, variables
holding information about the host for the build to use (like: does
this site want html-docs built?) etc.
For this to work, required packages might need to be installed in
well-known places, so that my package could do (load
"cclan-lib:clx/clx-lib") or whatever.
-- footnotes:
1: The client must obviously check this before unpacking, and will
thus be able to determine the name of this directory, but most likely
it will be called <packagename>-<version>.
2: This might be where required packages come in. I'm a newbie at
lisp, so I don't know how defsystem would handle external
dependencies. In the prototype stage builds would fail, and you'd have
to go to cclan and manually download the required stuff.
3: Or maybe an alist like ((:html . ("p/a.html" "p/b.html"))
(:man . "packagename.man")
(:ps . "packagename.ps"))
--
H�kon Alstadheim, Montreal, Quebec, Canada
I got in on this late, so forgive me if I repeat things already said...
www.FreeBSD.org has a very slick system for keeping up-to-date on
modules, called "ports". You download (or have pre-installed) the
makefiles and packing lists for an app (including dependencies). To
install a browser package on your local machine (e.g.):
cd /usr/ports/www/linux-netscape47-communicator
su
make install
The system grabs the binaries (or source) from a list of ftp servers
thought to exist, resolves dependencies, and voila, a working netscape.
It has never failed me, and would be a good example to follow, I think.
Eric
"H�kon Alstadheim" wrote:
>
> Daniel Barlow <···@telent.net> writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > I am not familiar with PERL "module" conventions (of CPAN conventions)
> > > could anybody summarize them here (saving me time :) )
> >
> > A Perl module as downloaded from CPAN is a tar.gz file that unpacks
> > into its own directory - typically the module Foo::Bar is called
> > Foo-Bar-0.81 or something. Having unpacked it you run perl
> > Makefile.PL ; make ; make test ; make install and it installs itself
> > where perl can find it and its documentation where perldoc can find
> > it.
>
> I'd say "perl Makefile.PL;make" corresponds fairly well to what
> mk:defsystem can do. Thus, I'd say the logical packaging scheme for
> cclan would be a tarball with a <packagename>.system file inside. A
> cclan client would then download the tarball, unpack it and do
> (operate-on-system <packagename> ...)
>
> "make test" would correspond to having a "test.lisp" inside the
> tarball that would be loaded after the package was compiled.
>
> "make install" would require that anyone who wished to fully automate
> the use of the cclan system defined a logical directory into which a
> cclan client app could copy the compiled files/docs. All packages
> could be required to provide a list of files to install
> (documentation, binaries).
>
> So my preferred setup would be something like this:
>
> To be a well-behaved cclan citizen a package must meet the following
> criteria:
>
> A) It must be a tarball containing only one directory and no files
> at the top-level.[1]
> B) The tarball must contain _one_ file in the top-level directory
> whose name ends with .system. This file will be used by
> mk:defsystem. [2]
> C) The tarball must contain a file "test.lisp" in the top-level
> directory which must define a function "packagename:test". If
> this function evaluates non-nil after calling (operate-on-system
> "packagename" :compile), the build will be considered to have
> failed, and installation will halt.
> D) The tarball must contain a file "install.lisp" in the top-level
> directory which defines:
>
> +) *packagename-docs* wich is a list of files or directories that
> belong in a documentation directory.[3]
> +) *packagename-binaries* which is a list of binaries (without
> extension) that belong in a library directory.
>
>
>
> A cclan client programs could then automatically call
> (operate-on-system ...) and then copy the resulting files into
> "docs:packagename/" and "lib:packagename/".
>
> The perl CPAN (packages and client) elaborate on all theese with
> things like a standard format for the output of the tests, variables
> holding information about the host for the build to use (like: does
> this site want html-docs built?) etc.
>
> For this to work, required packages might need to be installed in
> well-known places, so that my package could do (load
> "cclan-lib:clx/clx-lib") or whatever.
>
> -- footnotes:
> 1: The client must obviously check this before unpacking, and will
> thus be able to determine the name of this directory, but most likely
> it will be called <packagename>-<version>.
>
> 2: This might be where required packages come in. I'm a newbie at
> lisp, so I don't know how defsystem would handle external
> dependencies. In the prototype stage builds would fail, and you'd have
> to go to cclan and manually download the required stuff.
>
> 3: Or maybe an alist like ((:html . ("p/a.html" "p/b.html"))
> (:man . "packagename.man")
> (:ps . "packagename.ps"))
> --
> H�kon Alstadheim, Montreal, Quebec, Canada
In article <·················@pacbell.net>, Eric Moss wrote:
> I got in on this late, so forgive me if I repeat things already said...
>
> www.FreeBSD.org has a very slick system for keeping up-to-date on
> modules, called "ports". You download (or have pre-installed) the
> makefiles and packing lists for an app (including dependencies). To
> install a browser package on your local machine (e.g.):
>
> cd /usr/ports/www/linux-netscape47-communicator
> su
> make install
>
> The system grabs the binaries (or source) from a list of ftp servers
> thought to exist, resolves dependencies, and voila, a working netscape.
>
> It has never failed me, and would be a good example to follow, I think.
>
> Eric
I was reading an article in daemon news(print version) about how there
is a new and improved ports package comming out. It is suposed to
support the different varients of BSD including Darwin and fix some of
the problems with the current version of ports. If anybody is
interested I will see if I can find a url.
marc
I found the link:
www.openpackages.org
marc
In article <··················@oscar.eng.cv.net>, Marc Spitzer wrote:
> In article <·················@pacbell.net>, Eric Moss wrote:
>> I got in on this late, so forgive me if I repeat things already said...
>>
>> www.FreeBSD.org has a very slick system for keeping up-to-date on
>> modules, called "ports". You download (or have pre-installed) the
>> makefiles and packing lists for an app (including dependencies). To
>> install a browser package on your local machine (e.g.):
>>
>> cd /usr/ports/www/linux-netscape47-communicator
>> su
>> make install
>>
>> The system grabs the binaries (or source) from a list of ftp servers
>> thought to exist, resolves dependencies, and voila, a working netscape.
>>
>> It has never failed me, and would be a good example to follow, I think.
>>
>> Eric
>
> I was reading an article in daemon news(print version) about how there
> is a new and improved ports package comming out. It is suposed to
> support the different varients of BSD including Darwin and fix some of
> the problems with the current version of ports. If anybody is
> interested I will see if I can find a url.
>
> marc