Re: [Chicken-hackers] .egg -> .deb packaging issues

[Ivan Raikov]

   I am also still interested in packaging Chicken eggs for Debian. But,
to add to your list of issues, the current version of Chicken in Debian
testing is 2.5. There is a wishlist item filed to upgrade Chicken to
2.7, but so far no response on part of the package maintainer. So we
will either have to use unofficial Debian packages with more recent
Chicken, or find a way to get in touch with the maintainer:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418747

And I have some responses to the other issues below:

* package naming convention -- I actually prefer the naming convention
  for Common Lisp packages, which is cl-PACKAGE (in our case,
  chicken-PACKAGE). The libPACKAGE-LANGUAGE seems overly verbose.

* more extension repository locations -- good idea, I could use
  CHICKEN_LIBRARY_PATH to direct Chicken to look into my home
  directory  for extensions first. By the way, the current Debian
  location for Chicken extensions is /var/lib/chicken/<binary-version>.

* default repository for chicken-setup -- perhaps an even more
  sensible default would be to check if the current user is root, and
  if so, install the extension in the system-wide /var/lib/chicken,
  otherwise install into $HOME/var/lib/chicken, or something along
  those lines. What do people think?

>
>       With an APT-repository of Debian packages available, deploying
>       a feature-rich version of Chicken-based Scheme programming
>       environment could be made lightning-fast.  I believe this will
>       make Chicken a viable alternative to other languages (such as
>       Perl or Python), at least in Debian-based GNU systems.
>

  Preach on, brother ;-)

 
  -Ivan


Ivan Shmakov <address@hidden> writes:

>       I'm still interested in packaging pre-built binary extensions
>       for Chicken with `dpkg'.  There're a few issues still
>       unresolved, IIRC:
>
>       * Debian packages for other languages' extensions usually follow
>         libEXTENSION-LANGUAGE convention (e. g., libocamlnet-ocaml);
>         could this convention be adopted for Chicken's extensions?
>
>       * currently, Chicken seems to search for extensions in, roughly,
>           $CHICKEN_REPOSITORY and $CHICKEN_HOME; it's not enough, since
            >           there's to be a distribution-wide repository of 
pre-compiled
>           packages (/usr/lib/chicken/<binary-version>), a system-local
>           one (/usr/local/...) and a user's own one (e. g.,
>           ~/lib/chicken/<binary-version>); a facility for selecting any
>           number of directories to search for the packages needs to be
>           added (perhaps, a CHICKEN_LIBRARY_PATH environment variable);
>
>       * on the other hand, `chicken-setup' needs exactly one directory
>         to install the packages into; thus, CHICKEN_REPOSITORY
>         variable is to be preserved in its current meaning; BTW, as a
>         convenience, a default repository for `chicken-setup' could be
>         changed to point to a directory below $HOME; thus,
>         `chicken-setup' will behave sensibly even for non-privileged
>         accounts on system-wide Chicken installations;