Package System - XEmacs Packages -> Debian Packages (Was: Re: Sharing Guile source)

[karlheg at bittersweet dot inetarena dot com (Karl M. Hegbloom)]

>>>>> "Karl" == Karl M Hegbloom <karlheg@bittersweet.inetarena.com> writes:

>>>>> "Michael" == Michael Livshin <mlivshin@bigfoot.com> writes:

    Michael> how does the XEmacs package system integrate with Debian?  does it
    Michael> integrate with it at all?  I'd look myself but I still run Debian
    Michael> 1.3...

 That work remains to be done.  I've a small start on it, and I'm a turtle.

    Karl>  It's not set up for it at all.  I looked, six months ago or longer,
    Karl>  and very briefly, at creating packages of the lisp modules in the
    Karl>  cvs.xemacs.org[1] `xemacs-packages' repository, and found that it will
    Karl>  require quite a lot of work... (mainly because there's so many of
    Karl>  them)

    Karl>  I have not researched it much yet.  Before I can give you much of an
    Karl>  answer, I'll have to do that.

 I started looking into it today, and got a little side-tracked...
 Though I'm only about 50 buffers deep right now...  (like I said, I'm
 a newbie) I just worked up my (first cut) modifications to the XEmacs
 `xemacs-packages' build setup that will hopefully make the task
 simpler...  (It's hard for me to just READ stuff like that, and to
 resist the urge to fix a few things.)  I've not submitted those
 modifications to the xemacs-patches patch approval board yet, but
 will do so after they are tested.

 I read _some_ of the packages handling and building stuff in XEmacs
 also...

 You can see how this was done for yourself if you grab a copy via
 anonymous CVS.  See http://cvs.xemacs.org for information.

 For each package, there is a "Makefile".  It includes both a
 "Local.rules" and an "XEmacs.rules", which sit at the toplevel of the
 `xemacs-packages' CVS checkout.  The "XEmacs.rules" has double colon
 targets for "all", etc., and rulesets to create the
 "auto-autoloads.elc" and "custom-load.elc", as well as a package
 information file that consists of an alist entry generated from a
 template, the template having fill-ins, the values coming from the
 lisp package's "Makefile".

 A lisp script is called from the "Makefile" (via "XEmacs.rules"), and
 it reads the fill-in values from the command line, and edits the
 template.  Because double colon rules are used, additional actions
 and prerequisites can be specified on a per-package / per-target
 basis.  There is a standard set of variables that each package must
 define in it's "Makefile".  The "Local.rules" is for per-site global
 definitions, where you set up things like the STAGING directory, etc.
 There is, of course, a "Makefile" at toplevel that drives the entire
 build machine. A `make bindist' will generate all of the
 `xemacs-packages' lisp tarballs that are what XEmacs ftp's when you
 ask it to install something.  The package info alist entries are used
 to form a catalog for the ftp directory.

 XEmacs lisp "binary" packages are just tar files that are opened in
 the system xemacs package directory.  They contain the compiled lisp,
 the info, the data in the etc dir, and perhaps someday will also
 contain dynamic shared objects...  (though those are arch-specific and
 should be packaged separately with appropriate dependancies on the
 matching xelisp.)

 Because of the "auto-autoloads.elc"'s, when XEmacs is restarted, it
 automagicly finds all the newly installed Lisp.  There is a set of
 directories that are scanned at startup, which is set by a
 `configure' option, or a run-time environment variable.  It is broken
 into three parts, an early, a late, and a last part.  Each part may
 contain several directories, like PATH can.  Each of those
 directories serves as a package root, and under each are the subdirs
 "lisp/", "etc/", "info/", etc.  Under those subdirs there are subdirs
 per package (except for the case of "info/").  This is where the
 `load-path' gets initialized.

 When XEmacs is dumped, the "late" roots are scanned for
 "dumped-lisp.el" files, which tell it what to loadup and dump in.  At
 runtime, the early roots are first in load-path, the late second, and
 the last are of course at the end of the load-path.  This mechanism
 can be used to cause locally installed versions of packages or
 individual lisp files to shadow ones found later in the `load-path'.

 The DSO module path is separately configured, to handle the case
 where there are arch indep lisp as well as arch dep DSO's that ship
 with the package, so you can put the arch indep lisp in "share" and
 the arch dep DSO's in "lib", "share" perhaps being an NFS mount.

 Because each path may contain several root directories, it's possible
 to have <distrib> controlled packages under prefix=/usr, site-admin
 controlled packages under prefix=/usr/local, and per-user controlled
 packages under "~/.xemacs/xemacs-packages".

 That package info file (the alist entry generated from the template)
 serves the similar purpose, to XEmacs, as the debian/control file
 does for `dpkg'.  It contains the package name, the version, the
 author, a description of it, which other packages it depends on, etc.

 That's almost all I know about it right now.  Certainly there are
 details that I've omitted out of ignorance and in the interests of
 brevity.  (RTFS)

 My idea is that those package info files should, if they don't
 already, contain enough information to be used to auto-generate
 debian/control snippets from.  Thus, they serve both to inform XEmacs
 about what packages are installed for it, and to inform the Debian
 package generation setup (that I hope to eventually create) of what
 it needs to know to write the packaging control information.  (After
 that experience, I suppose I will have a much more qualified answer
 to your question.)  I won't have to create a separate packageing
 setup for every one of the myriad lisp packages there are - one at
 the toplevel can build and package the whole world.

 The main thing is that whatever guile's package manager adds to it's
 database and uses to track what it has available must contain enough
 info to tell debian/* what it needs to know.  This will enable
 separate packageing of each individual library from one consolidated
 version control repository.

    Michael> your input will be very valuable, because the problems look very
    Michael> similar.

 I hope my writing skill aren't all that horrible.  A comprehensive
 technical writing skills upgrade is on the docket.

    Michael> does the XEmacs package system support binary (dyn-linked) code in
    Michael> packages, or is it Lisp-only?

    Karl>  I don't know yet.

 Still don't for certain.  I think it does have at least preliminary
 support for that though.  I'm certain they have plans for one of some
 kind.  You might poke around at http://www.xemacs.org and find out
 something.  Likely there is clatter in the email archive regarding it.

    Karl>  I will take some time today to look it over and write up a report for
    Karl>  yous, which I'll mail to the list.  I'm waiting on a phone call -
    Karl>  might work today (I am flat broke and am going to temp for a while),
    Karl>  if so, I'll have to do the research/report this evening - but I'll
    Karl>  start on it right now.

 I will work tomorrow morning... but when I get home in the afternoon,
 I'll try to spend some time learning more about this.  I must limit
 it though...  I have a lot of reading I need to do.  My copy of SICP
 is only partly dogeard.