Package for system integration
I have packaged basex in a way that I believe will be easier for integration with package managers. https://klarinet.kos.ovh/fossil/basex-root-install/uv/basex-9.4.3.tar.gz
From the root of that archive, you can build and install like this.
make make install # as root The above will install to the prefix /usr/local. You can set a different prefix. Here is an example. make clean make PREFIX=/usr make PREFIX=/usr install # as root A secondary benefit of this package is the removal of the bash dependency. Could a package like this be distributed officially? If that is agreeable, I am happy to try incorporating this into the present build system. Here is a utility for preparing the package. It depends on sh and other Unix-like utilities. https://klarinet.kos.ovh/fossil/basex-root-install/dir?ci=tip With distinguished salutations, Kralj Karlo
Hi Kralj, Thanks for your packaging proposal, very appreciated. We’ll have a look at it in the near future. Would you recommend it as default distribution for all Linux systems, or are there possible restrictions that may need to be considered? The current build system is based on Windows (mostly due to the Windows executable that’s created). Maybe we could target a more platform-independent approach in future. Best, Christian On Mon, Sep 14, 2020 at 6:12 AM <karlo@fastmail.com> wrote:
I have packaged basex in a way that I believe will be easier for integration with package managers. https://klarinet.kos.ovh/fossil/basex-root-install/uv/basex-9.4.3.tar.gz
From the root of that archive, you can build and install like this.
make make install # as root
The above will install to the prefix /usr/local. You can set a different prefix. Here is an example.
make clean make PREFIX=/usr make PREFIX=/usr install # as root
A secondary benefit of this package is the removal of the bash dependency.
Could a package like this be distributed officially? If that is agreeable, I am happy to try incorporating this into the present build system.
Here is a utility for preparing the package. It depends on sh and other Unix-like utilities. https://klarinet.kos.ovh/fossil/basex-root-install/dir?ci=tip
With distinguished salutations, Kralj Karlo
Dear Christian, I recommend this style for now as the default binary package for GNU/Linux operating systems. It would also work well for BSD-derived operating systems. You probably weren't asking about Android, but since that also uses Linux, I note that I don't know whether this is how one installs software on Android. I propose three alternative routines for preparing the package. 1. We can use the previously linked (and now attached) "build" file at the end of the build process. It relies on the basex zip package and on some Unix-style utilities. I am happy to be the one to run it. 2. I can assist a BaseX developer in rewriting my packaging utility with maven and Java in a way that will run on Windows. It would still be run at the end of the build process, after the zip file. 3. If someone documents how to build BaseX with command-line utilities, that is, without Eclipse, I will look into packaging the whole build process for Unix-like operating systems. Option three is best. It is best because only this option produces a source package that can be built on Unix-like operating systems in a conventional way. Options one and two are still good because they at least produce a convenient binary package. Please receive my sincere salutations. Kralj Karlo
Hi Kralj, thanks for your efforts on packaging BaseX for Linux. Very appreciated! You might have already seen that we did some packaging for Debian GNU/Linux [1], but it is currently not very up-to-date. Would you be interested in revising and adopting the process? Would be of great help :-) Cheers, Alex [1] https://github.com/BaseXdb/basex-dist/tree/master/linux
On 16. Sep 2020, at 13:06, karlo@fastmail.com wrote:
Dear Christian,
I recommend this style for now as the default binary package for GNU/Linux operating systems. It would also work well for BSD-derived operating systems. You probably weren't asking about Android, but since that also uses Linux, I note that I don't know whether this is how one installs software on Android.
I propose three alternative routines for preparing the package.
1. We can use the previously linked (and now attached) "build" file at the end of the build process. It relies on the basex zip package and on some Unix-style utilities. I am happy to be the one to run it. 2. I can assist a BaseX developer in rewriting my packaging utility with maven and Java in a way that will run on Windows. It would still be run at the end of the build process, after the zip file. 3. If someone documents how to build BaseX with command-line utilities, that is, without Eclipse, I will look into packaging the whole build process for Unix-like operating systems.
Option three is best. It is best because only this option produces a source package that can be built on Unix-like operating systems in a conventional way.
Options one and two are still good because they at least produce a convenient binary package.
Please receive my sincere salutations. Kralj Karlo <build>
Alexander Holupirek writes:
You might have already seen that we did some packaging for Debian GNU/Linux [1], but it is currently not very up-to-date. Would you be interested in revising and adopting the process? Would be of great help :-)
Dear Alexander, I did see that package. It doesn't install the bin files conveniently like the one I prepared. Once we begin releasing a version of the style that I proposed, it will be simpler to package for Debian and other specific operating systems. Since you focused on Linux, I remind you that this style works well for Unix-style operating systems, independent of kernel. For example, this packaging style should make for simple porting to OpenBSD, Cygwin, Mac, and Debian, and I don't think it be helpful for Android. Cordially, Kralj Karlo
Hi Kralj, Thanks for your generous offer to prepare future packages for us. I would also target your third option and try to automatize the process as far as possible. This way, you won’t need to feel responsible for all the time coming. The core of our packaging routine is an ancient Perl script [1]. The main reason why we haven’t switched to a more seasonable approach is that the script has been running for more than 10 years without causing noteworthy issues. It’s being run on a Windows machine, and it’s used as part of a (local) pipeline for both the snapshot and the official releases. One of the steps in this script is the invocation of Maven for creating the .war Web Archive. It would surely be handy if we managed to add a Maven goal for creating the .tar.gz file. Another solution would be to create the archive with some custom code that (ideally) runs on Windows. Setting UNIX permissions might be one specific issue to look at; in perl, that was resolved by invoking a unixFileAttributes function when creating the ZIP archive. Alex, who has replied earlier to you, has spent valuable time in our Debian distribution. He may also have another look at your packaging code. In the past, we also had packages for openSUSE, Fedora, CentOS and other Linux distributions. Maybe we’ll manage to revive them again. I’ll be offline for most of the next two weeks, so sorry in advance for possibly letting you wait. Best, Christian [1] https://github.com/BaseXdb/basex-dist/blob/master/release.pl On Wed, Sep 16, 2020 at 1:06 PM <karlo@fastmail.com> wrote:
Dear Christian,
I recommend this style for now as the default binary package for GNU/Linux operating systems. It would also work well for BSD-derived operating systems. You probably weren't asking about Android, but since that also uses Linux, I note that I don't know whether this is how one installs software on Android.
I propose three alternative routines for preparing the package.
1. We can use the previously linked (and now attached) "build" file at the end of the build process. It relies on the basex zip package and on some Unix-style utilities. I am happy to be the one to run it. 2. I can assist a BaseX developer in rewriting my packaging utility with maven and Java in a way that will run on Windows. It would still be run at the end of the build process, after the zip file. 3. If someone documents how to build BaseX with command-line utilities, that is, without Eclipse, I will look into packaging the whole build process for Unix-like operating systems.
Option three is best. It is best because only this option produces a source package that can be built on Unix-like operating systems in a conventional way.
Options one and two are still good because they at least produce a convenient binary package.
Please receive my sincere salutations. Kralj Karlo
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.
participants (3)
-
Alexander Holupirek -
Christian Grün -
karlo＠fastmail.com