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 <[email protected]> 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
