Hello --
I'm utterly confused with the status of end-user package installation.
The whole thing just seems esoteric for a lisb newbie, there's
practically no documentation (from my point of view), and the
documentation - if there is one - doesn't help much.
It seems the Debian common-lisp-controller has been superseded by a new
method, the vn-cclan, is this correct? How does cclan, vn-cclan and
common-lisp-controller relate?
I don't understand where the packages are, what I need to do to install
them under this new system. As a matter of fact, I don't understand the
old common-lisp-controller, too. The learning curve is very steep as we
read about namespaces, sockets, servers and the like, when all I needed
today was a little chunk of code already written and tested...
Is there - alas - a Common LISP code repository that has been proposed in this
very newsgroup? Did the whole thing just die? It doesn't seem to me, but
I can't extract the necessary information, even though I look and I keep
looking around on the web. From what I understand, they wanted to make
things uniform, and provide a way for easy installation, usage, and
exchange of packages/code.
Can anyone explain and put the rest of us newbies up-to-date?
Thank you very much.
Yours truly,
H.
PS: I am concerned with free/libre/public domain software only.
--
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
···········@debian-rs.org
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
Ok, this is an auto-reply, sorry. For the register: it is soooo easy for
Debian. I just wanna register things here in case another newbie has
difficulty, so he/she may surch the usenet and have an answer. The
information is a bit dispersed on the Net, but it's there.
Turns out, it's easier than it looks (if your using Debian).
Just apt-get install common-lisp-controller
Then apt-get install the packages you see at
http://cclan.sourceforge.net/, more specifically for i386 at:
http://cclan.sourceforge.net/packages/i386-Packages.html
then you #apt0get insall <package> as would normally.
On Sat, 24 Aug 2002 01:34:58 -0300, synthespian wrote:
> Hello --
>
> It seems the Debian common-lisp-controller has been superseded by a new
> method, the vn-cclan, is this correct? How does cclan, vn-cclan and
> common-lisp-controller related?
cclan uses the common-lisp-controller and is designed for Debian, because
Debian already had a very good package management system.
vn-cclan attempts to be independent of the "vendor".
I haven't figured out how vn-cclan works, though.
> Is there - alas - a Common LISP code repository that has been proposed
> in this
> very newsgroup?
Apparently, there are 2 current code respositories:
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/0.html
http://cclan.sourceforge.net/
cclan apparently has the vn-cclan repository.
The way packages are made differ, it seems: common-lisp-controller
follows Debian policy (and thus can be ported to RedHat), vn-cclan uses
ASDF and there seems to be a new CL-CONFIGURATION tool that doesn't
depend on MK:DEFSYSTEM (whatever that is).
That rounds it up.
If anyone would be kind enough to expand on these issues, newbies would
be grateful. We will catch on sooner or later...;-)
Cheers
H.
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
···········@debian-rs.org
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
From: Daniel Barlow
Subject: Re: [partially SOLVED] Re: What's the current status for end-user package installation?
Date:
Message-ID: <87it1ya4qi.fsf@noetbook.telent.net>
synthespian <···········@debian-rs.org> writes:
>> It seems the Debian common-lisp-controller has been superseded by a new
>> method, the vn-cclan, is this correct? How does cclan, vn-cclan and
>> common-lisp-controller related?
>
> cclan uses the common-lisp-controller and is designed for Debian, because
> Debian already had a very good package management system.
> vn-cclan attempts to be independent of the "vendor".
> I haven't figured out how vn-cclan works, though.
cclan uses the common-lisp-controller and is designed for Debian.
Creating common-lisp-controller packages for Debian is tedious and
easy to get wrong, so vn-cclan is a work in progress which will
eventually allow the mechanical creation of Debian packages (and other
package formats - Solaris pkgs, Red Hat rpms, etc) from a more "light
weight" package format that we can easily create or (ideally from our
point of view) that the original package author might even want to
create himself.
This more lightweight format is a tar file containing all of the
source code and an ASDF-compatible system definition.
When the vn-cclan project has advanced at least to the point that it
can make good quality Debian packages, the current Debian-style cclan
repository (which is actually fairly stale already anyway) will go
away in favour of an automatic conversion of the vendor-neutral
packages. There will be only one cclan and it will be vendor-neutral.
> The way packages are made differ, it seems: common-lisp-controller
> follows Debian policy (and thus can be ported to RedHat), vn-cclan uses
> ASDF and there seems to be a new CL-CONFIGURATION tool that doesn't
> depend on MK:DEFSYSTEM (whatever that is).
asdf ("Another System Definition Facility") and mk-defsystem are both
system definition utilities, which are given a data file (the system
definition) describing the source files and work out which of them
need what doing to them to compile or load the complete package.
There's a rough analogy with Unix-style "make" tools.
We (vn-cclan, which will one day be cclan) use ASDF instead of
mk-defsystem 3 because the latter doesn't have the introspection
features that we need to do the job reasonably, and, after its
development over ten years that (if one believes the fossil record)
started back in the time when most CL implementations didn't even
support pathnames in any remotely standard fashion, it's time for it
to die. No such slight is intended towards mk-defsystem 4, which is
apparently a ground-up rewrite that actually uses CLOS, but which
we're not using because it didn't exist when we started.
common-lisp-controller currently uses mk-defsystem 3, but has hooks
for asdf, which our autoconverted Debian packages will eventually take
advantage of (so, yes, they will be Debian policy compliant)
CL-CONFIGURATION is unrelated to CCLAN, though may be working in a
similar problem space. I'm sure Marco will be along to explain it ad
to plug defsystem 4 if he hasn't already by the time I post this :-)
Anybody who is interested in asdf as a free (MIT-style license)
defsystem that doesn't (yet?) have all the cruft of mk-defsystem 3, or
in the workings of cclan, can probably find most of the relevant links
starting at http://ww.telent.net/cliki/asdf
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Marco Antoniotti
Subject: Re: [partially SOLVED] Re: What's the current status for end-user package installation?
Date:
Message-ID: <y6c4rdheho7.fsf@octagon.mrl.nyu.edu>
Daniel Barlow <···@telent.net> writes:
> synthespian <···········@debian-rs.org> writes:
>
...
>
> > The way packages are made differ, it seems: common-lisp-controller
> > follows Debian policy (and thus can be ported to RedHat), vn-cclan uses
> > ASDF and there seems to be a new CL-CONFIGURATION tool that doesn't
> > depend on MK:DEFSYSTEM (whatever that is).
>
> asdf ("Another System Definition Facility") and mk-defsystem are both
> system definition utilities, which are given a data file (the system
> definition) describing the source files and work out which of them
> need what doing to them to compile or load the complete package.
> There's a rough analogy with Unix-style "make" tools.
>
> We (vn-cclan, which will one day be cclan) use ASDF instead of
> mk-defsystem 3 because the latter doesn't have the introspection
> features that we need to do the job reasonably, and, after its
> development over ten years that (if one believes the fossil record)
> started back in the time when most CL implementations didn't even
> support pathnames in any remotely standard fashion, it's time for it
> to die. No such slight is intended towards mk-defsystem 4, which is
> apparently a ground-up rewrite that actually uses CLOS, but which
> we're not using because it didn't exist when we started.
Yep. MK:DEFSYSTEM 4.x (MK4) is in ALPHA stage in the CLOCC. Real
work got in the way :) You can get the current CVS module named
`defsystm-4.x' from the CLOCC site. Note that there are four modules
named `cl-environment', `cl-configuration', `defsystem-3.x, and
`defsystem-4.x' which are "stand alone". I.e. you do not need to
download the whole CLOCC to use them.
As for MK4, I just finalized a design for supporting external
compilers and languages. That was the major stumbling block. Once I
will be able to recompile `matlisp' - or, better, clg - flawlessly (or
if anybody will be able to :) hint, hint) a public announcement for
MK4 1.0 will be made.
> common-lisp-controller currently uses mk-defsystem 3, but has hooks
> for asdf, which our autoconverted Debian packages will eventually take
> advantage of (so, yes, they will be Debian policy compliant)
>
> CL-CONFIGURATION is unrelated to CCLAN, though may be working in a
> similar problem space. I'm sure Marco will be along to explain it ad
> to plug defsystem 4 if he hasn't already by the time I post this :-)
CL-CONFIGURATION is a little utility that overlaps with
common-lisp-controller. If MK:DEFSYSTEM 4.x and ASDF are "make" tools
for Common Lisp, CL-CONFIGURATION is a "autoconf".
CL-CONFGURATION is a 100% CL tool which will work on the (old) MacOS
and Windows. It does not address some of the things that c-l-c does,
but, IMHO does address others. CL-CONFIGURATION does depend on the
presence of a defsystem utility, but that is not so necessary as I
look at it more deeply. Anyway, the idea of CL-CONFIGURATIOn is to
centralize some of the dependencies and set up operations you may
need for your package. Essentially you want a form (possibly
segregated in a separate file) like
(conf:defconfiguration "MY-GIZMO" ()
(:logical-pathname-host "MYGIZMO")
(:library-location "/my/gizmo/goes/here/" :os-type :unix)
(:library-location "C:\\Program Files\\My Gizmo\\" :os-type :ms-windows)
(:required-system "MAIN-SYSTEM" :system-type :mk)
(:required-system "META-SYSTEM" :system-type :asdf)
(:required-system "PORTABLE-ALLEGROSERVE" :system-type :acl)
(:required-module "comm")
)
When executed on a Linux OS the above will generate a CONF:SETUP
method that will eventually set up the logical pathname translations
for "MYGIZMO" using the approriate definition as discriminated by the
:os-type keyword, and ensure the presence of the "required" components.
The CONF:SETUP method can be called with a :library-location
parameters changing the default specification of the DEFCONFIGURATION
form.
AFAIK, the above subsumes several of the ad-hoc macros that appear in
several packages. E.g. the DEFLOGICALPATH you find in Matlisp.
You may argue that the facilities provided by CL-CONFIGURATION should
go in a "defsystem" utility. Maybe yes. I just like to keep things
separate.
I encourage people to play around with CL-CONFIGURATION. It is bound
to have bugs in it, so, the more people use it, the better bug
swatting will happen.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th 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'.