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

[Ivan Shmakov]

>>>>> Ivan Raikov <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:

 > 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,

        I believe it's quite acceptable for now.

 > or find a way to get in touch with the maintainer:

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

        Or, if the maintainer has lost his interest to maintain the
        Debian package, a new maintainer has to make a step forward.

 > 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).

        Python packages follow the same convention, BTW.

 > The libPACKAGE-LANGUAGE seems overly verbose.

        It's just three letters more long.

 > * 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>.

        Yes.  And the reason is, in my opinion, the inability to search
        for extensions in multiple locations.

 > * 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,

        I disagree with using /var as a place to install software.  FHS
        specifies /usr/lib[/PACKAGE-NAME] and
        /usr/local/lib[/PACKAGE-NAME] as the appropriate locations for
        libraries.

        Debian Bug#388644 reads:

--cut--
Chicken-setup installs extensions (eggs) to /usr/lib/chicken which might be
mounted as read-only.

http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#PURPOSE31

"/var is specified here in order to make it possible to mount /usr
read-only. Everything that once went into /usr that is written to during
system operation (as opposed to installation and software maintenance)
must be in /var."
--cut--

        However, using `chicken-setup' is clearly falls below
        ``installation and software maintenance'', thus /usr and
        /usr/local are the appropriate locations.

        As soon as Chicken will support searching for libraries in
        multiple locations, /usr should be made a designated place for
        dpkg-installed libraries, while /usr/local should be used for
        the ones installed by `chicken-setup' (as root.)

        Of course, it applies only to FHS-compliant systems.  Different
        systems may have different policies regarding the filesystem
        hierarchies and Chicken shouldn't enforce FHS-based policy on
        non-FHS-compliant systems.

 > otherwise install into $HOME/var/lib/chicken, or something along
 > those lines. What do people think?

        `$HOME/lib' could be a default place for user to install his own
        set of libraries.

        Personally, I prefer following the FHS layout (although not very
        closely) for /usr in my `$HOME'.  As in:

$ mkdir build
$ cd build
$ ../configure --prefix="$HOME" ...

 >> 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 ;-)

        Well, either Chicken will become more rapid to deploy, or I'll
        get fired.  (Or I'll have to switch to Perl, or
        Python... doesn't looks like a good outcome at all.)