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

[Emmanuel Charpentier]

Hi, Jörgen !

Le jeudi 18 mai 2023 à 17:17 +0200, Dr. Jürgen Sauermann a écrit :

Hi Emmanuel,

I believe your efficiency formula is incorrect.

when I said:

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.

I did not mean that the work moved from the user to the maintainer
is essentially the same for both. After maintaining GNU APL for more than
10 years I can tell you that saving 1 minute per user in the build system can
easily take weeks for the maintainer.

That, assuming my initial estimate, would put a threshold of about  ×/7 24 60 =  10080 Gnu APL users to justify maintainance. Worldwide, that's not much...

But I think that the kind of restructuring I had in mind has probably a steeper bill... 

My computation would be this:

1. from the feedback on bug-apl@gnu.org I would assume that there are
    less that 10 libapl users in this world (most use the GNU APL interpreter).

That's where we differ : what I had in mind was putting libapl at the *core* of the package, the interpreter being but one ppplication using that core. Therefore making a libapl user af all and any gnu-apl user...

Under* your*  assumption, the rest of your reasoning looks perfec correct to me.

2. running configure --with-libapl ; make ; sudo make install
 takes less than 2 minutes.

3. This amounts to a total of 20 minutes for all users.

4. Your proposed packaging scheme will take 20 hours of my time
   (at least - I am not at all familiar with Debian packagintly.

5. Apart from that, GNU APL handles the presence or non-presence
   of a package in the source code. For example ⎕FFT will produce a
   SYNTAX ERROR, generate the )MORE command information related
   to the SYNTAX ERROR, etc. if libfftw3 is missing. I severely doubt that
   such fine-tuning can be managed with package managing alone, at
   least not in 20 hours.

5a. Debian would simply fetch libfftw3 if missing. However, I had several
    cases in the past where the automatic loading of packages crashed my
   entire machine badly (the last event of that sort was only a few weeks ago,
   and I still have not fully recovered from that crash). I therefore want
   GNU APL to be as little intrusive as possible,

That's interesting ! Did you report this to Debian ? This might reveal a *Debian* bug...

What I had in mind was the work necessary to compensate for the introduction *in the system directories* of libraries unknown to the package management system (apt, friends, cousins, nephews twice removed and other distant relatives :-). In >20 years of Debian use, I became wary of messing with this holy mafia...

Intrducing unknown  libraries implies that manual maintainance operations *have* to be done at each change of configuration of the APL packages *or change in the client programs configuration !* The latter may become a pain...

Sincerely,

--

Emmanuel Charpentier

Best Regards,
Jürgen


On 5/17/23 13:29, Emmanuel Charpentier wrote:

Partial answer to soime of your points (most of them being well taken ! ). More later...

Le mardi 16 mai 2023 à 13:45 +0200, Dr. Jürgen Sauermann a écrit :

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.

The same is true for most development environments. I'll take the example of R in Debian :

There is :

• a base package r-base-core, which contains the very core of the interpreter ;

• the basic interpreter, r-base, which uses r-base-core, and therefore depends on it :

• about 138 packages (in Debian testing) depending on r-base including various documentation presentation packagings), therefore indirectly depending on r-base-core ;

• 1121 packages wrapping CRAN R packages, all depending more or less directly from r-base[-core]? and possibly other.

The dependencies avoid Debian to have to produce 2^159 packages... Furthermore, other packages (e. g. ess might recommend or suggest R packages and/or other R-related packages.

I thought that such a combination could be created for APL packages. That would be :

• gnu-apl-base-core : essentially libapl.so, containing the core of the interpreter ;

• gnu-apl-base: the "vanilla" user interface, essentially emulating a 70's terminal, callinglibapl.so` functions for all the APL computations ;

• various gnu-apl-xxx wrappers, depending of either gnu-apl-core or gnu-apl-base and calling (directly or not) libapl.so for APL computation, allowing APL to interface with either :

  • service processors, such as various SQL interface to databases (sqlite3, mysql, postgresql, etc...)

  • interface to other languages/services (C, Python, erlang, possibly emacs, etc...).

    Each of them might depend also on distribution-specific packages guatranteeing a known configuration for each of them. For example, gnu-apl-python could depend on gnu-APL-base-core and python3, as well as any python3-xxx packages providing a useful service.

These dependencies avoid the necessity to create a zillion packages representing the various combinations you decsribed. In other words, gnu-apl-base-core does nothing by itself but enables other functionalities without duplication.

I suppose that the same can be done in rpm and yum packaging systems.

[ Hypothetical Debian gnu-apl package : Snip... ]

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.

That's the point ;-)... Don't yell too fast :

This restructuration is indeed more work (say W_m) for one (or n) maintainer(s), and less work (W_u) for any of the N users.

This is efficient if W_m/W_u≤N/n.

In other words, managing these dependencies is worthy if you believe that "easy management" will attract more potential APL users...

In (yet) other words, that's an investment.

This restructuration might also have long-term benefits in terms of cleanliness of the code v=base, but I'll refrain to exress any opinion about this : while I'm (relatively) competent enough in C to be able to fix a bung in a lbrary, my C++ is rudimentary to the extreme. For about 30 years, I've worked almost exclusively with higher order languages, such as R, perl, bash, and (more recently) Python and Sage (throw in enough emacs-lisp to survive heavy daily usage of emacs...), and that's no happenstance...

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

I need to experiment with the Debian build package before answering this.

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

I'm a special case : since my (almost) homonym, Emmanuelle Charpentier was awarded a Nobel prize, my mail feeds (especially the professional ones) are flooded with spam. I tend to be extremely cautious about subscribing to mailing lists...

Sincerely,

--
Emmanuel Charpentier