bug-apl
[Top][All Lists]
Advanced

[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: Thu, 18 May 2023 17:17:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

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.

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

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

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,

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 :

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 :

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.

  1. put the desired libraries into a tar file
  2. 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]