Arch Linux

LinuxSquare

Member

Registered: 2023-08-17

Posts: 20

unusual versioning of upstream software - how do I proceed?

Hi there

I'm currently creating (trying at least) a PKGBUILD for the tax evaluation software of the canton of St. Gallen in Switzerland (I will refer to it as "etaxes software").
Here's the url, for anyone interested: https://www.sg.ch/steuern-finanzen/steu … sonen.html

As the title may suggest, the upstream software does have an unusual versioning. Instead of having each version as a separate downloadable file, the download provides an install4j application, which directly pulls the latest version of the etaxes software when executed.
Since this is in my opinion bad practice, it's unknown for me, how to correctly create a PKGBUILD and how to suffix the package for this software.

Normally, I'd be in charge to update to the latest software-version via my PKGBUILD.
In this case however, I don't have any control about the update-procedure of the software, which is bad.
So far I'd just go with the year as the pkgver, of the currently available etaxes software.

Coming to the naming of the pkgname: if I'd pull the latest changes of a git-repo, it would be clear, that the pkgname should have the -git suffix.
If it would be a repackage for an existing binary (.rpm / .deb) it would carry the -bin suffix.
In this case I'm not sure, if the pkgname even needs a suffix.

Since the versioning is not in my hands, is this PKGBUILD even allowed to be pushed to the AUR?

Does anyone have any experience with this kind of upstream software?
I'd appreciate any help.

mithrial

Member

Registered: 2017-03-05

Posts: 78

Re: unusual versioning of upstream software - how do I proceed?

Very nice! I'm in need for this program, hopefully, it's done by end of March

Typically, what is done, You would have to turn off the self-update mechanism and provide your own updates. It would not be a -git because it's closed source. And it's not -bin because it's not a binary distribution of a prebuilt open-source package.

The currently published version is 1.2.0 (seen on the Info/About screen). I would use this. How you get to this version, I don't know.

It must be a different package for each year because you could install e.g. the 2023 version along the 2024 version.

Last edited by mithrial (2025-02-18 20:38:06)

LinuxSquare

Member

Registered: 2023-08-17

Posts: 20

Re: unusual versioning of upstream software - how do I proceed?

Typically, what is done, You would have to turn off the self-update mechanism and provide your own updates.

This is the tricky part, I was referring to.
Since the install4j installer is always installing the latest version of the software, this seems quite impossible as of now.
There also isn't a way to disable auto-updates via env-variable or a install4j parameter: https://www.ej-technologies.com/resourc … tions.html

The "script" which gets downloaded is a "binary" and will be actively checked when running if something got changed inside the script.
(Editing the script will result in a corrupt binary)

As long I can't figure out how to convert a shell-script back to a binary format, editing the script seems not possible.
Also, the installer contains binary data, which is not possible to edit without somehow reverse-engineering the software.

The currently published version is 1.2.0 (seen on the Info/About screen). I would use this. How you get to this version, I don't know.

Since the download-url doesn't contain a tagged version of 1.2.0 (or any release) the download of a specific version seems not possible in the way, the canton of Thurgau is releasing it's software: https://aur.archlinux.org/cgit/aur.git/ … =efisc-bin

It must be a different package for each year because you could install e.g. the 2023 version along the 2024 version.

Understood, will keep this in mind. Actually I would've went the way like I did in efisc-bin, by releasing the software as "one PKGBUILD" and keeping it up-to-date for the current version of the actual year

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 13,529

Re: unusual versioning of upstream software - how do I proceed?

The download script is basically an archive with some additional code to deal with extracting/installing the archive contents .

To make a package for it you will have to find some way to extract the binary data from the script.

Does it require root rights to install ?
In case it doesn't , not packaging it may be a better choice.

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

LinuxSquare

Member

Registered: 2023-08-17

Posts: 20

Re: unusual versioning of upstream software - how do I proceed?

Does it require root rights to install ?

No, the script can be run as user and it'll install the java-application in a separate directory inside $HOME.

To make a package for it you will have to find some way to extract the binary data from the script.

Well, this is gonna be tricky, I could however try to use the same steps as the installation script is doing and put it inside the build() function.
This however seems already like reverse-engineering to be, which definitely is illegal and will be followed by the authorities.

not packaging it may be a better choice.

Well this is gonna be the case, if I don't manage to create a package and don't find a way on how to manage the version independently from the install4j installer.