Arch Linux User Repository

In v4.9.0-2 I've experimentally added the aarch64 architecture. Please test it, someone. TIA!

Thanks for being a co-maintainer.

The provides field tells other packages what this package, well, provides: e.g., awk', gawk, mawk and nawk could all provide=('awk') if they had a binary called awk with a behaviour equal to the reference AWK implementation (this is just an example).

In our context, soupault-bin and possibly a soupault-git would provide the same functionality as the soupault package (had it been compiled from the sources), so a user can choose any of these to fulfill a dependency.

As for your soupault package:

The package has 3 votes, so presumably someone is using it. To alert them of the fact, I would bump e.g. the pkgrel (to force an update for anyone with the package installed), and then add a prepare() function that would alert people to install soupault-bin instead:

prepare() {
  echo 'This package has been replaced by "soupault-bin".' >&2
  echo 'Please install that package instead.' >&2
  exit 1
}

and change build() to e.g.:

build() {
  false
}

This prevents the package from being built, and forces people to take a look at the outpout: that they should switch to the binary package.

Then just disown the package. Hopefully, an OCaml expert will pass by and adopt the package to compile from the sources.

Being a co-maintainer works for me since that's alright with you. Thank you for the quick reply and for experimenting with aarch64!

Should I delete the soupault PKGBUILD, or is it necessary for the provides in this PKGBUILD?

In v4.9.0-2 I've experimentally added the aarch64 architecture. Please test it, someone. TIA!

@mcode10 Thanks for reaching out.

How would you like if either (1) you took over the soupault-bin package here, or (2) if I add you as co-maintainer and then the one of us who sees there is a new release will do a git pull on the AUR repo and update the package?

About the aarch64: I have no devices where I can test this, but I am wondering if we skip the usual sha256sums and rely solely on the minisign signature for tampering protection, then we could possibly rely on a single source with a $CARCH variable in a stategic place. I haven't tried, I'm just thinking aloud.

Hello @kseistrup!

I just got a chance to look at the conversation as I was about to bump soupault to 4.9.0.

I must have misinterpreted the AUR docs as I thought that if there was no package bin or otherwise avaliable, you could submit a package omitting it even if it was just a binary. As you can probably see from my profile, soupault is the only package I maintain. Sorry for the confusion!

I think your PKGBUILD for soupault-bin is great, and if you want to keep maintaining it, I'm happy to delete soupault or modify it.

If you do continue maintaining soupault-bin, is it possible to add aarch64 support to your PKGBUILD? I learned that you can specify sources and checksums specific to aarch64 or x86_64 and seeing as Daniil provides both binaries (usually), it makes sense to support both architectures. My latest PKGBUILD lacks this because he did not provide a binary for aarch64 for 4.8.0, but my PKGBUILD for 4.7.0 has support for both architectures as an example. I am not sure if this would still work with minisign though...

As for providing a true compiled-from-source build, I did attempt it several times, but I have never worked with OCaml, and do not know anything about the build system Soupault uses, Dune. Ultimately, I had issues getting it to work and have not had enough time since to pursue it. If you know how to compile an OCaml source, I would appreciate your help.

Let me know what you want to do!

@m040601 I don't feel any attachment to the -bin package, so I'm sure it will work out.

One more benefit of this package is that the binary is checked with minisign to ensure it hasn't been tampered with (IMHO, all packages should use minisign instead of PGP, so we don't need to import PGP keys from left and right).

Happy policing. I'm sure the overall usability of AUR is better because of what you do.

...so it will be silly to delete soupault-bin.

I personally also agree. But I dont decide anything. Let's just hope "mcode10" also agrees, and cooperates with you. I left a note there.

In any case, the most important end result, is the AUR end user experience.

kseistrup commented on 2024-03-24 12:54 (UTC)

... I assumed that the soupault package would build the application from the source

And you did it right. It is a reasonable assumption. But the thing is that AUR is getting flooded by not so experienced users not naming the PKGBUILD correctly. Forgetting to use "xyz-git" or "xyz-bin". I myself only spotted it, because I'm trying to contribute to an AUR cleanup. And I am getting quick at spotting these kind of errors.

.... so I decided to create a package with a name that shows that installed from a pre-compiled binary.

Thanks for you effort. This "-bin" alternative sure is needed for those fat Ocaml tools. And Go and Rust. Always ask to download Megabytes just to compile.

... soupault is written in OCaml, not in Go ....

Yeah my mistake, I got that wrong.

I only landed here, because I spotted "soupault" on mastodon or twitter and something about "Hugo alternative".

And I somehow "suspected" it would already be on AUR. Goshhh ... I love Archlinux ...

I'm a drug addict for new toys and static site generators.

Eager to try out this "... generator based on HTML element tree rewriting ... as a robotic webmaster ..." . Whatever that is :-)

PPS: And as you point out, soupault-bin is the “correct” package name so that users will not be confused — plus is has “pre-compiled” in the description so that there can be no doubt — so it will be silly to delete soupault-bin. I will happily turn soupault-bin over to @mcode10 if he wishes to maintain it. He knows where to reach me.

Oh, and PS: The soupault is written in OCaml, not in Go, which is which I didn't want a source install in the first place.