[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is the recompilation of the Debian package with support libraries po
From: |
Dr . Jürgen Sauermann |
Subject: |
Re: Is the recompilation of the Debian package with support libraries possib le ? |
Date: |
Tue, 16 May 2023 13:45:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 |
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