FR: Debian APT repo

[pazos]

Does your feature request involve difficulty completing a task? Please describe.

Updates on debian based distros require to pull the last release from github and update the package manually with dpkg or apt.
Same happens for new installations.

Describe the solution you'd like

https://apt.koreader.rocks is a debian repo containing the last stable version for the following archs arm64, armhf and amd64.

https://earthly.dev/blog/creating-and-hosting-your-own-deb-packages-and-apt-repo/ contains instructions on how to do it (step 2 onwards).

Describe alternatives you've considered

Current behaviour is not extremely bad 😄

Additional context

There're are a bunch of debian targets in kodev which just generate plain linux releases and then call do_debian_package.sh. The final .deb packages are then released on each tagged release.

There's at least one linux package downstream which is generated downloading our debian release and converting to another kind of package. I'm talking about https://aur.archlinux.org/packages/koreader-bin

The intention would be substitute all debian-arch targets in kodev with linux-arch targets, which generate a koreader-version-arch.tar.{gz/xz} and modify do_debian_package.sh to work with those archivers.

The changes to do on the repos are easy but I have no idea of the current workflow @Frenzie does on releases.

I'm assuming kodev release debian is called once for each supported arch.

The new workflow would be kodev release linux for each supported arch + a script that does the conversion to deb packages and updates the repo.

With this new workflow we can choose what to publish on releases:

• Debian packages as we're doing now.
• Linux tar.gz packages (kind of broken since they have external dependencies on sdl2 and noto fonts)
• None of them.

Releasing tar.gz packages would make possible for downstream to use them as a source of their own packages instead of using the debian ones.

[pazos]

Also: remove debian-armel packages. That's an arch with no future and no current usage. If they're downloaded I guess it is without clue and just to download the proper debian-armhf to install when dpkg/apt says armel is not supported.

armhf has no future as well but there're a bunch of Rpi clones out there than can make use of it, so it is cool to release it.

[Frenzie]

All the packages we build are defined in https://gitlab.com/koreader/nightly-builds/-/blob/914e23f966c0e13307fe072501e46bb8697937fd/.gitlab-ci.yml

The Debian packages are an exception in that they're not automatically downloaded by the script over in https://github.com/koreader/koreader-misc/blob/a77d73015f49575ecc2e2cc6ea6718c9f05742a6/nightswatcher/nightswatcher.py but I grab the four of them by hand for each release. The other files I currently grab with a wget on the relevant stable (such as http://build.koreader.rocks/download/stable/v2022.06/) which I then drag into the GH release window.

The nightswatcher script could be extended to do something special with the DEB files.

[pazos]

Thanks for the info. A few yay/nay questions?

1. Build generic tar.gz instead of deb files? ie: ./kodev release linux-arm64instead of./kodev release debian-arm64`.

if yay:
1.1 Should these generic linux archives be self contained (ie: include sdl2 and the fonts), so they can be used without external dependencies?. That doesn't mean include them in debian. They can be stripped later on.

1.2 Should the script that makes debian packages be called once for each arch or should be called just once and convert all tar.gz packages to the corresponding deb ones?

2. An apt repo in apt.koreader.rocks?

if yay:
1.1 What bits of code need to be done to automate the process?.

1.2 Do you see it as uggh, to much work?, as I won't be bothered by it if my workflow is the same? as yay, I'm willing to help this clueless contributor and do most of the work myself? or as other: please fill?

[Frenzie]

1.1 Should these generic linux archives be self contained (ie: include sdl2 and the fonts), so they can be used without external dependencies?. That doesn't mean include them in debian. They can be stripped later on.

I would imagine so.

1.2 Should the script that makes debian packages be called once for each arch or should be called just once and convert all tar.gz packages to the corresponding deb ones?

I imagine once for each arch. And then it should automatically call the .tar.gz process first, and the GitLab action should have two artifacts (since presumably making the deb out of the .tar.gz takes mere seconds).

An apt repo in apt.koreader.rocks?

I don't really know what's involved in terms of keys and all. It might be a bit annoying to set and maintain compared to doing something with https://build.opensuse.org/? (Also I'd leave a special subdomain as the last concern for the moment.) Quick search result: https://www.percona.com/blog/2020/01/02/how-to-create-your-own-repositories-for-packages/

1.1 What bits of code need to be done to automate the process?.

If we did it as part of our regular process, build on GitLab, further handling in nightswatcher.py.

1.2 Do you see it as uggh, to much work?, as I won't be bothered by it if my workflow is the same? as yay, I'm willing to help this clueless contributor and do most of the work myself? or as other: please fill?

I can do nightswatcher and GitLab, particularly the nightswatcher part. (By which I mean the GitLab CI part should be a complete non-issue.)

[pazos]

1.1 Should these generic linux archives be self contained (ie: include sdl2 and the fonts), so they can be used without external dependencies?.

I would imagine so.

Gave it a try today. SDL2 has too many dependencies on linux (ldd /usr/lib/x86_64-linux-gnu/libSDL2.so)

Makes sense to rely on distro's sdl. After all we do the same with libc.

also

Should we replace ./kodev release linux-$(ARCH) with
LINUX_ARCH= ./kodev release linux, like in other platforms ?

[Frenzie]

The way I see the kodev script it should be setting that, perhaps simply by splitting on -. I just never bothered to adapt it like that.

[benoit-pierre]

Should we replace ./kodev release linux-$(ARCH) with LINUX_ARCH= ./kodev release linux, like in other platforms ?

I totally went the other way when patching kodev in my meson branch: ./kodev build android-arm, ./kodev run android-x86… IMHO, the fewer environment variables, the better.

[Frenzie]

How does that deal with kodev build android-maybe-this-arch-will-just-work? There's a certain flexibility there I found helpful, hence my choice to write it that way. It doesn't need to be represented that particular way but I'd rather such flexibility be present than not.

[benoit-pierre]

You can't have support for an arch without dedicated code in Makefile.defs, the cmake toolchain, etc… So it make sense that kodev only handle supported targets.

[benoit-pierre]

And you can bypass kodev completely, which I rarely do on my meson branch, but almost always do on other branches. (Because of the duplicated (broken) logic for testing, finding output / install directories, KODEBUG default, etc…)

[Frenzie]

Alright.