Dear Kralj,
That’s a great contribution; I really appreciate your efforts.
A little while ago, Bridger asked users on the list to share their experiences installing and running BaseX. It would be great if those of you who are using Linux and UNIX-based systems could have a look at Kralj’s package and tell us about your observations!
Thanks all, best regards, Christian
On Sun, Jun 20, 2021 at 8:36 AM karlo@fastmail.com wrote:
Dear Christian,
With your help I have prepared a new version with a similar user interface but that also builds BaseX. The released binaries run perfectly of course, so the role of the source build package is to demonstrate that the binaries are built from a free source.
Because the package follows certain conventions, we can quickly prepare BaseX for many different operating systems and maintain BaseX packages for several package repositories.
I explain the method in more detail below. For those who are just joining the discussion, I include some background before continuing the discussion about this package.
I have the honor to be Your Majesty's humble and obedient servant.
Kralj Karlo
INTRODUCTION
BaseX has a bespoke procedure initiating builds. If the build could instead be initiated through execution of "make" in a directory with the conventional inputs, it would be fast to port to the many different operating systems whose packaging systems follow this convention.
I propose a procedure to create BaseX source packages. The resulting BaseX source packages contain a Makefile with instructions for building and installing from source.
I create the source package as a directory containing the basex source code, the basex-dist source code, a version-specific Makefile, and other files to support the build.
I distribute the source package, and someone else can build it. A build of the source package produces a tree that can be installed by unpacking to the specified PREFIX, /usr/local by default.
To build it within the framework of a package manager, you would configure the package manager to retrieve the source package and, possibly, set a different PREFIX, set the dependencies, and copy other package metadata (for example, homepage and description). The package manager will likely already have tooling around the "make" and "make install" commands, so you should not really need to understand the build process.
PROCEDURE
Copy the program for creating the source package. https://klarinet.kos.ovh/fossil/basex-make/tarball/basex-make.tar.gz
You can alternatively use fossil, for example:
fossil clone https://klarinet.kos.ovh/fossil/basex-make ../basex-make.fossil fossil open ../basex-make.fossil
I run "make update prune all tgz" from the basex-make directory to do the following.
- Download the latest sources and copy them to ./basex-src
- Generate the file ./basex-src/Makefile for building the sources.
- Archive the directory basex-src as basex-src.tar.gz
Now I can send the basex-src.tar.gz to someone else. Here it is. https://klarinet.kos.ovh/fossil/basex-make/uv/basex-src.tar.gz
Then you can extract basex-src.tar.gz and run "make && make install" to build and install. That does the following.
- Build BaseX by the conventional process.
- Unpack the zip file created by the conventional BaseX build.
- Replace the conventional executibles. The new executables handle the PREFIX and are written in sh rather than bash.
BUGS
- With this installation method BaseX looks for the configuration file $PREFIX/lib/BaseX$VERSION/.basex and creates it if it does not exist. It would be good to change that to look for $HOME/.basex instead.
- Certain vendor libraries are still distributed as binaries in basex/basex-core/lib. I plan to remove these so we can truly call it a "source" package.
- basex-src.tar.gz should instead be named BaseX$VERSION.tar.gz, and it should contain a directory named BaseX$VERSION instead of basex-src.
NOT BUGS
- The minor complexity of this process is unfortunate. It would be nice to modify release.pl so there are fewer layers, but this could break other things that depend on the present build process.
APPLICATION
I propose that a tarball like that created by the present procedure be distributed on the BaseX download webpage (https://basex.org/download/) and that it be addressed as the "Source Package" with support for all Unix-like operating systems. I believe it will in fact work on Windows with Cygwin, but I don't care to support that.
Once we have begin releasing source packages, we proceed to add BaseX to various package repositories. I think we would start with Debian apt, because we have already done one of those, and OpenBSD ports, because that's what I use.
On Mon, 2021-06-21 at 14:51 +0200, Christian Grün wrote:
It would be great if those of you who are using Linux and UNIX-based systems could have a look at Kralj’s package and tell us about your observations!
The things that are binary-only, if they have a compatible licence, could either be included or added in a separate package.
I don't remember BaseX having an especially unusual build system compared to other Java applications.
Yes, it should look in $HOME for a conf file.
I'd say that Ubuntu and Fedora (and Centos 7?) would be good targets, since they are widely used on servers these days.
I'm a bit maxed out right now or I'd offer to do Mageia Linux at least, and maybe Cenots 7, although the Fedora rpm should work fine in both cases.
It would be awesome to see BaseX in major Linux distributions.
Liam
Liam R. E. Quin writes:
The things that are binary-only, if they have a compatible licence, could either be included or added in a separate package.
Indeed, when registering it with a package repository, we would replace those binary libaries with dependent packages from the repository.
Liam R. E. Quin writes:
Yes, it should look in $HOME for a conf file.
Even better, ${XDG_CONFIG_HOME:-${HOME}/.config}
Where does basex set the location of the configuration? If you point me to the file, I might try changing it.
basex-talk@mailman.uni-konstanz.de