GSoC 2023 proposal to add XWiki to the AUR

Help / Discuss
,
#1

hello everyone,
While browsing through the xwiki-snap package distribution list, I noticed that the majority of of the users using xwiki-snap were using Debian-based Linux distributions. (ubuntu,debian,linux mint)
debian_based

This may be due to multiple factors, like out-of-the-box support for snap packages, etc.
Thus, to make XWiki more accessible to developers using Arch Linux-based distributions, I would like to package the XWiki for the Arch User Repository (AUR).

The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains a package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg, and then install it via pacman.
Most arch linux users prefer to use the AUR over the snapcraft because:

  • faster load time: aur packages load faster compared to their snap counterpart.
  • lightweight: aur packages are lightweight since they do not come with all of their dependencies installed.
  • More Control: With AUR, you have more control over the software you install. You can customize the software packages to meet your specific needs, and you have the ability to modify the software before installation.
  • No Snapsd: Snap relies on a daemon called snapsd to run in the background and manage snap packages. AUR does not require any background daemon or service to operate.

To build a clean, working package of XWiki and publish it on the AUR, only a PKGBUILD script would be required. (similar to snapcraft.yaml in Snaps).
The following script can be made using the xwiki .deb packages, xwiki .zip package, and the .war package.
Using the .war package doesnā€™t seem feasible as the entire source code would be needed to be compiled and would be much harder to maintain.

Using the .deb packages as a core component seems like the ideal approach. Programs like Debtap can be used to convert DEB packages into
arch linux packages Although far from perfect, I used Debtap to convert quadrapassel_3.32 a .deb package into a arch linux package.
There were a lot of dependency issues that, once resolved (by editing the PKGBUILD manually), would produce ideal results.

A PKGBUILD file can be created from scratch for the XWiki .zip package. I have recently tried packaging TIRAMISU(a notification daemon) (Github-link). It helped me get a better understanding of how to package for the AUR. Thus making a PKGBUILD for XWiki .zip file wouldnā€™t be much of a hassle. But using the .deb package would be ideal.
Integrating them into the release process would be a high priority, along with automating as much as possible.

I would love to get your valuable feedback and input on the following proposal :slight_smile:

#2

Sounds like a nice idea, yes, if that can be automated and does not require too much maintenance (Iā€™m afraid we donā€™t have many Arch Linux users in the team to fix the package if something needs to be changed).

Note that for your idea to work, the AUR needs to have packages for at least the following (which are not provided by the XWiki Debian packages) to have a fully working XWiki instance:

  • Java 11
  • Tomcat 9 (or Tomcat 8, but it would be more future-proof to be based on Tomcat 9)
  • at least one of those: MySQL, MariaDB or PostgreSQL servers
1 Like
#3

The AUR does have working packages of JDK, MySQL, and tomcat8.

Automating the release process would be a necessity(top priority) for the following project.

Will start working on my proposal. Looking forward to your valuable feedback on the proposal.
Thank you : )

#4

@Pol donā€™t forget to start sending your proposal(s) ASAP so that we can review and suggest improvements.

1 Like
#5

hey @tmortagne ,
Thanks for the reminder just submitted the proposal. Would love to hear your feedback on the following : )

#6

What are the main challenges for creating an AUR package for XWiki? You write that you already tried it, so whatā€™s missing between what you have and what you want to create?

Automating the release process should be relatively simple, you replace the version variable, generate the checksum, replace it in the package and push the git repository with the package. So this could be automated with a few lines of shell script I think - or am I missing something?

#7

hey @MichaelHamann ,
I tried converting the XWiki .deb package to the AUR package using the debtap script . It leads me to multiple dependency issues.
Debtap cannot be 100% accurate for several reasons, the main reason for this is the complexity of package names. Thus I donā€™t plan on relying on debtap as the primary tool for this project as it would be very unreliable.Debtap was written to create packages that either cannot be compiled (closed source packages) or cannot be built from AUR for various reasons (error during compiling or unavailable files), as a quick ā€˜nā€™ dirty solution and an extra option for creating Arch Linux packages for Arch Linux users. I am planning to use it as an aiding tool to help me generate the PKGBUILD file for XWiki from scratch. (using the .deb package ideally or the .zip package if the first one fails) .Using the -p tag in debtap script generates a basic PKGBUILD file for XWiki which could serve as a good starting point. I could Start building the PKGBUILD from scratch after this point and make sure all the dependencies are satisfied. (making sure that the files are editable, unlike my last GSoC experience wherein the snap package made the files uneditable. Thus customization was hindered initially for the snap package ) This was my initial thought process for the project. I was planning to do more research and work on the following topic during the community bonding period of GSoC 2023.

It seems that I was mistaken, as I have not yet attempted to automate the release process for an AUR package. Therefore, I was unaware of the challenges involved and had allocated a significant amount of time in my proposal to learn and create a script for automating the release process. As I mentioned earlier, I plan to conduct further research and testing on this topic during the community bonding period. I hope that the process turns out to be as straightforward as you have suggested, but I will remain open to any difficulties that may arise.

Thank you for your valuable feedback : )

#8

@Pol would be nice to give more details on what you plan the AUR package(s) will contain. You mention the XWiki deb package, but you should indicate more precisely which variations you plan to provide in the context of the GSOC and why since there are a lot of possibilities, and they are not all interesting depending on the context (Tomcat 8, Tomcat9, MySQL, MariaDB, PostgreSQL, Jetty, HSQLDB, etc.).

#9

sure I plan on using the xwiki-tomcat9-mysql .deb package(for the first build). Currently, the AUR has tomcat 8, tomcat9, MySQL, PGSQL, jetty, and MariaDB packages available in the AUR. We can technically build the following packages -

  • xwiki-tomcat8-mariadb - XWiki Tomcat 8/MariaDB based package
  • xwiki-tomcat9-mariadb - XWiki Tomcat 9/MariaDB based package
  • xwiki-tomcat8-mysql - XWiki Tomcat 8/MySQL based package
  • xwiki-tomcat9-mysql - XWiki Tomcat 9/MySQL based package
  • xwiki-tomcat8-pgsql - XWiki Tomcat 8/PostgreSQL
  • xwiki-tomcat9-pgsql - XWiki Tomcat 9/PostgreSQL
  • xwiki-zip

If the GSoC timeframe allows we could build the more than one package . I dont plan on using the other packages as they do not offer a completely out-of-the-box experience. They have to be configured and setup . eg.

  • xwiki-common
  • xwiki-mariadb-common
  • xwiki-mysql-common
  • xwiki-pgsql-common
  • xwiki-tomcat8-common
  • xwiki-tomcat9-common
    Have the users configured the database or the application server.
    The goal I have in mind for the application is similar to the XWiki-tomcat9-mysql .deb package where the package is already preconfigured on installation and has a seamless upgrade process.

I would make sure to update the proposal on the following :slight_smile:

#10

Those are not independent packages, but dependencies for more final ones. xwiki-tomcat9-mysql contains almost nothing, its main job is to combine the others and add the missing pieces.

#11

okay

The AUR package that I plan on building will also just combine the database, the application server, and XWiki. It would technically be not very different from xwiki-tomcat9-mysql deb package just wonā€™t utilize those dependency packages and directly add those dependencies from the AUR.

will update the GSoC proposal accordingly.
Thanks, Thomas : )

#12

Is there a reason to use these packages from the AUR? Apart from Jetty, all of these packages seem to be available in the regular Arch Linux repositories so as a user I would find it preferable if the AUR package depended on these instead of some AUR package. If an AUR package depends on many other AUR packages, thatā€™s usually a reason for me to not to install it as AUR packages are basically untrusted (they can be created by anybody) and thus I need to review every package and update manually. Further, AUR packages tend to be abandoned so it is also much easier to end up with broken software if a package needs many AUR dependencies.

#13

It appears to be an excellent substitute. Additionally, I believe employing the Arch Linux repository package instead of the AUR packages would be preferable, as it would simplify the building and maintaining process significantly. :slight_smile:

#14

How would it simplify the building and maintaining process? I just said you should use the dependencies from the regular repositories instead of the AUR, I donā€™t see how this would change the maintenance process.

#15

In the case of upgrading a dependency, it is generally a good practice as Outdated packages can pose a threat to security and can have negative effects on performance. Up-to-date packages prevent vulnerabilities. This means that periodic dependency checks and updates are important.
It would be a good idea to use the Arch repository package instead of the AUR package. Due to the reasons, you suggested:

  • packages get abandoned quickly in AUR
  • official repository can be a trusted and tested source compared to AUR

Remaining building of the XWiki AUR package would not be impacted significantly only the source would be altered along with a few changes : )

.

#16

But updates of dependencies would be handled by pacman for packages from repositories automatically, there is no need to update anything from the side of the XWiki AUR package. If the dependency is from the AUR, there is still nothing to update from your side, itā€™s just that either the administrator uses some helper application to build and update AUR packages (semi-)automatically or the administrator would manually need to re-build and then update the AUR package. So as Iā€™ve said, Iā€™m not sure how this would simplify the maintenance.

Btw., what do you mean with ā€œbuildingā€ the AUR package? The AUR is not a package repository, just a collection of build scripts. Do you plan to provide a repository with pre-built packages?

#17

okay, if the dependencies are already taken care of by Pacman for the Arch Linux repository package then it would not really aid the maintenance process. Then the only advantages of the Arch Linux repository package over the AUR package would be expected longer support and trustworthiness of the source. Thanks, Michael : )

No, I do not plan on providing pre-built packages just the PKGBUILD that would be hosted on AUR. I am not opposed to the idea of hosting the pre-built package somewhere else. But it seems redundant as the package could be easily built from the PKGBUILD script using makepkg.

The building I was referring to was creating or generating the PKGBUILD file. Would use creating or generating to prevent further misunderstandings.

#18

Updated the Path of execution section on my GSoC proposal. Would love to get your feedback on the following :slight_smile: