Unable to install into /boot/system/non-packaged/lib from .hpkg file

I am packaging Regina Rexx interpreter for Haiku and am running into problems with installing one of the packages.

Regina Rexx has the capabilities to run external functions provided by other packages such as Rexx/CURL. The external functions are packaged in a shared object and need to be installed into a single location so the Regina Rexx interpreter can find them.

I am using /boot/system/non-packaged/lib to install the external functions as this is the only location that appears to be writeable by more than one hpkg package.

However when I install libregina3-3.9.6-1-x86_64.hpkg the files and directories in non-packaged are not created. See the results of

package list libregina3-3.9.6-1-x86_64.hpkg

package-attributes:
        name: libregina3
        summary: The Regina Rexx interpreter. Shared library.
        description: Regina is an implementation of a Rexx interpreter, compliant with
the ANSI Standard for Rexx (1996).
        vendor: Mark Hessling
        packager: Mark Hessling <mark@rexx.org>
        architecture: x86_64
        version: 3.9.6-2
        copyright: 1992-1993 Anders Christensen
        copyright: 1993-2022 Mark Hessling
        license: GNU LGPL v2
        URL: link removed
        source URL: link removed
        provides: libregina3 = 3.9.6
lib                                      0  2024-05-26 10:20:51  drwxr-xr-x
  libregina.so.3                         0  2024-05-26 10:20:51  lrwxrwxrwx  -> libregina.so.3.9
  libregina.so.3.9                 1868448  2024-05-26 10:20:51  -rw-r--r--
non-packaged                             0  2024-05-26 10:20:51  drwxr-xr-x
  lib                                    0  2024-05-26 10:20:51  drwxr-xr-x
    regina-rexx                          0  2024-05-26 10:20:51  drwxr-xr-x
      addons                             0  2024-05-26 10:20:51  drwxr-xr-x
        libregutil.so               294832  2024-05-26 10:20:51  -rw-r--r--
.PackageInfo                           712  2024-05-26 10:20:52  -rw-r--r--

Looking in /boot/system/non-packaged/lib I see that Python 3.10 has a directory structure. The contents of the Python 3.10 hpkg are:

package list python3.10-3.10.13-3-x86_64.hpkg

package-attributes:
        name: python3.10
        summary: An interpreted, interactive, object-oriented programming language
        description: Python is a programming language that lets you work more quickly and integrate your systems more effectively. You can learn to use Python and see almost immediate gains in productivity and lower maintenance costs.
...
non-packaged                             0  2024-02-14 03:22:30  drwxr-xr-x
  lib                                    0  2024-02-14 03:22:30  drwxr-xr-x
    python3.10                           0  2024-02-14 03:22:30  drwxr-xr-x
      site-packages                      0  2024-02-14 03:18:47  drwxr-xr-x
        README.txt                     119  2024-02-14 03:18:47  -rw-r--r--
.PackageInfo                          1914  2024-02-14 03:22:37  -rw-r--r--

ls /boot/system/non-packaged/lib
perl5 pkgconfig python2.7 python3.10

The non-packaged structures in the hpkg files look the same. How is it that the Python hpkg file works and libregina3 hpkg doesn’t?

Thanks for any assistance, Mark

1 Like

The python package uses the “global writable files” feature. You can see it declared in the HaikuPorts recipe but I don’t remember off the top of my head how to do it when building packages by hand.

Thanks for the quick reply.

I did some digging and you use: global-writable-files in the PackageInfo file.

Did that , built package and now my package list has a line:

global writable file: non-packaged/lib/regina-rexx/addons directory keep-old

Compared to the Python package list:

global writable file: non-packaged/lib/python3.10/site-packages directory keep-old

Again they look the same, and unfortunately still no directory created in /boot/system/non-portable/lib

Thanks, Mark

It’s a bad idea to package files, which live in boot/system/non-packaged/lib.

2 Likes

I have solved the problem.

The line I had in PackageInfo was:

global-writable-files {
             "non-packaged/lib/regina-rexx/addons directory keep-old"
           }

It should have been:

global-writable-files {
             "non-packaged/lib/regina-rexx/addons" directory keep-old
           }

Note the location of the ending quote.

Thanks for the help, Mark

As I’m a newbie packaging Haiku, then can you suggest an alternate single location to install application addons that can be installed by multiple packages?

Looking at /boot/system/non-packaged/lib there are directories there for both Python and Perl which appear to be used for a similar purpose to what I’m trying to do; a single location for the respective interpreter to locate addons to the interpreter.

Thanks, Mark

Ideally the interpreter would search in both packaged and non-packaged locations on disk. This would allow you to avoid putting a binary file in the hpkg which gets installed to non-packaged but still allow the user to install add-ons afterwards.

Edit: Also, I don’t think that file will be updated when you install newer versions of the package since that directory will be marked as “keep-old”.

The way this works on other platforms like Linux is there is a directory owned by the interpreter and when an external function package is installed, it installs its shared library in its own “addons” directory and a post install script creates a symbolic link from the external function package’s shared library in its own “addons” directory to the non-packaged/lib/regina-rexx/addons directory.

I tried doing this first but the symbolic link could not be created in /boot/system/lib/regina-rexx/addons because it is a read-only filesystem.It now works with a location in which the symbolic link can be created.

The need for the interpreter to look in multiple locations would be a solution only for Haiku and would add a small amount of performance overhead, but I will look into doing this.

Thanks, Mark

Maybe the hpkg should include the extra binaries in a data directory and have a symlink from that file in the data directory to the non-packaged add-ons directory. Possibly created/updated by a post-install script.

Sounds like what I’m doing, just the extra binaries are in “lib”; eg for Rexx/CURL: /boot/system/lib/rexxcurl/2.1.1/addons/librexxcurl.so is linked to /boot/system/non-packaged/lib/regina-rexx/addons

Right, but in your original post it shows the libregina3 package with a file in non-packaged/lib/regina-rexx/addons/libregutil.so. That file should be moved to the packaged area of the filesystem and linked to the correct location instead.

Yes, good point! I was only concentrating on the extra package files, not the ones included in regina-rexx. I will do that.

Thanks, Mark