Re: Is the recompilation of the Debian package with support libraries possib le ?

[Dr . Jürgen Sauermann]

    Hi Emmanue;

On 5/15/23 23:23, Emmanuel Charpentier wrote:

> Dear list,
>
> after a 37 years (!) hiatus, I have the opportunity to come back to
> APL. Gnu apl appears to be the easiest way to do that, at least
> partially due to emacs' gnu-apl-mode package, which appears to be a
> great interface.
>     
    Thank you very much for your interest in GNU APL.
> However, I wondered why the Debian package distributed by Gnu comes
> without support for libapl.so and lib_gnu_apl.so libraries,which would
> allow to use APL from other interface.
>     
    Actually GNU APL has 8 at least primary build options (see the
    script
    build/build_all line 309) :
    
      configs="standard develop tar git libxcb rational \
               libapl parallel_bench erlang python"
    
    The most common options are standard (the interpreter) and libapl.
    
    Each of these options has maybe 10 or so variants which differ
    depending on which libraries are installed on the build system.
    
    And then there are 3 or more packaging systems (debian, rpm,
    yum, ...).
    
    And finally there are different platforms (i386, amd64, arm, apple,
    ...).
    
    So in order to be fair we would need to produce several millions of
    binary packages.
    
    As far as Debian is concerned:
    
    1. There is a GNU APL Debian Package under preparation:
    
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949948
    
    However its severity is wishlist and it is open since 2020.
    I would not expect too much from that.  would also doubt
    that Debian wants to build libapl.
    
    2. GNU APL can build Debian packages (make DEB in the
    top-level directory,
    
    3. However:
    
    3a. The GNU APL ./configure scripts adapts the GNU APL
    sources to the libraries and #include files that are present
    on the build machine (at build time)
    
    3b. In the case of binary Bebian package, this means that
    ./configure runs on the Debian packager`s machine and not
    on the user's system. Debian addresses this problem via package
    dependencies (apt get on the user's machine would ideally
    fetch all packages that were present on the packager's system
    but missing on the user's machine.
    
    3c. GNU APL does or may (I don't quite remember) depend on
    libraries for which no Debian package is available but which
    have to be fetched (by the user) from some git repository.
    This causes problems when using the Debian packaging
    system, but none if building from source.
    
    3d. To summarize: building GNU APL from source ls much
    simpler and also far more reliable than distributing it via
    Debian packages.
> An obvious use case would be the creation of a gnu APL kernel for
> Jupyter : I tried Dyalog's interpreter and its Jupyter notebook kernel,
> and appreciated the result, but Dyalog's software is not free (even
> when it's gratis).
>     
    Actually, libapl is the GNU APL kernel. It is GNU APL with
    the standard interactive APL interface stripped of (and left
    to the user of libapl).
> Another use case would be a minimal ob-apl package allowing the
> inclusion of APL code and results in an org document, a form of writing
> I use more and more...
>
> Both of these use cases could be covered by a "clever" use of expect
> (or pexpect, in Python's case), but interfacing with libraries would
> probably be much easier.
>
> Furthermore, keeping a *packaged* version of APL makes its maintenance
> much easier.
>     
    Au contraire. It merely moves the work from the user to the
    package maintainer, and the work for the maintainer is bigger
    than the work for the user.
> So I'm looking for hints and advice on how to recompile and repackage
> APL for Debian(-like) systems with libraries support (I am aware that
> this possibly could result in the creation of distinct packages, at
> least for lib_gnu_apl.so : libapl.so could be part of the main apl
> package, where the binary apl could be a user front end calling it for
> computation).
>     
    This should be quite simple:
    
    1. ./configure GNU APL to build libapl (see README-2-configure).
    2. make
    3. sudo make install
    
    This should have created some /usr/local/lib/apl/libapl.* (static
    library libapl.a and/or dynamic library libapl.so; the exact names
    depend on your platform.
    
    4. put the desired libraries into a tar file
    5. convert the tar file into a deb file (e.g. dpkg-buildpackage).
    
    After all, a deb file is simply an ar archive that
    contains a tar
    archive  and some meta information (control.tar.zst, you may
    use debian/* for a start):
    
    eedjsa@server68:~/apl-1.8/debian_tmp$ ar
        tvf apl_1.8-1_amd64.deb
        rw-r--r-- 0/0      4 Jan  4 13:14 2014 debian-binary
        rw-r--r-- 0/0   5162 Jan  4 13:14 2014 control.tar.zst
        rw-r--r-- 0/0 2973074 Jan  4 13:14 2014 data.tar.zst
> Secondary question : it appears that this part of Ubuntu, but not of
> Debian. Do you know why ?
>     
    See above. Ubuntu is Debian based but also includes non-Debian
    packages, Some Ubuntus include GNU APL, some do not.
> BTW : I'm not (yet) on the list, so I would appreciate a Cc:
> emm.charpentier@free.fr of your (eagerly awaited) replies.
>     
    You only need to subscribe:
    
    https://lists.gnu.org/mailman/listinfo/bug-apl
> Sincerely,
>
> --
> Emmanuel Charpentier
>
>