Github messages for voidlinux
 help / color / mirror / Atom feed
From: meator <meator@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: Package request: Tachidesk-Server 
Date: Fri, 02 Feb 2024 10:25:18 +0100	[thread overview]
Message-ID: <20240202092518.6EFA92153E@inbox.vuxu.org> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-48155@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 3841 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/48155#issuecomment-1923402533

Comment:
The void-packages repository expects the packages to be built by it. This is one of the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements) and you specified that it fulfills the Compiled requirement in this issue. GitHub releases usually contain prebuilt binaries. void-packages doesn't distribute these[^1]. Void packages usually use the `Source code (tar.gz)` asset of releases[^2].

### Recommended changes to template

5: [You don't have to specify a build style](https://github.com/void-linux/void-packages/blob/master/Manual.md#build-style-scripts). The default one already defines `do_fetch()` and `do_extract()`.
12: `distfiles` should use the `version` variable. A standard package update procedure involves changing two lines: `version` and `checksum`. When `distfiles` relies on `version`, it doesn't have to be changed in an update.
16-18: This can be removed (when the `build_style` is removed). Also xbps-src prefers bsdtar over tar. bsdtar is installed on every masterdir by default (because it is a dependency of `base-chroot` which is installed on masterdirs), tar has to be added to `hostmakedepends` manually. Also xbps-src uses bsdtar internally.
22: Your build is failing because you are using the wrong distfile described above. `gradle` is already packaged in Void, so it should be used. I don't know gradle well, but some googling showed me that the purpose of the `gradlew` script is to download `gradle` automatically. You should add `gradle` to `hostmakedepends` and use it directly[^3]. I've also seen some templates use the `--no-daemon` flag, that can be useful.
25-28: That doesn't look like it's doing any checking (but I don't have much experience with Java). If the package doesn't have any checks, don't define `do_check()`.
32,34: All package files[^4] **must** be put to `${DESTDIR}`. Your template is currently polluting the masterdir.
34: I don't think `vln` exists. Use `ln` instad.

Here is the template modified with my and classabbyamp's suggestions:

```bash
# Template file for 'Tachidesk-Server'
pkgname=Tachidesk-Server
version=0.7.0
revision=1
hostmakedepends="openjdk8 gradle"
depends="openjdk8"
short_desc="A free and open source manga reader server written in Kotlin"
maintainer="jaminW55 <wellerbp@protonmail.com>"
license="MPL-2.0"
homepage="https://github.com/Suwayomi/Tachidesk-Server"
distfiles="https://github.com/Suwayomi/Suwayomi-Server/archive/refs/tags/v${version}.tar.gz"
checksum=ba18fa09ac4b7a1703d054da1ae8ff6d55af3b3b4d88b874260725ff94011656

do_build() {
	. /etc/profile.d/jdk.sh
	gradle --no-daemon build
}

do_install() {
	# TBD
}
```

This template doesn't work, but it's closer to the desired result. I do not have experience with gradle nor Java, so I can't really help more with this.

[^1]: There are some exceptions to this rule, void-packages contain some `-bin` packages, but it is discouraged.
[^2]: This asset is generated automatically by GitHub for every release. It is a snapshot of that repository at that tag (excluding submodules). Some repositories don't have releases, but have tags. The process is very similar.
[^3]: But I've also read that version mismatch between repo's gradle and the real gradle can create problems. The repo looks like it wants `gradle-7.6`, Void packages `gradle-8.5`. In that case, using `gradlew` might be necessary. But these problems should be solved by someone more knowledgeable of gradle, I have never used it.
[^4]: Things that should actually be present in the resulting package, I don't mean the source code nor intermediate build artifacts, these belong to `wrksrc`.

  parent reply	other threads:[~2024-02-02  9:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10 18:02 [ISSUE] " jaminW55
2024-01-15  5:56 ` jaminW55
2024-01-15  6:03 ` classabbyamp
2024-01-15  6:09 ` jaminW55
2024-01-15  6:36 ` jaminW55
2024-01-15  6:39 ` classabbyamp
2024-01-15  6:59 ` jaminW55
2024-01-21  1:24 ` oreo639
2024-01-21  1:40 ` classabbyamp
2024-01-21  1:42 ` classabbyamp
2024-02-02  9:25 ` meator [this message]
2024-02-07  3:20 ` jaminW55
2024-02-07 19:22 ` jaminW55
2024-02-08  6:50 ` jaminW55
2024-02-12  1:02 ` jaminW55
2024-02-12  1:02 ` jaminW55

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240202092518.6EFA92153E@inbox.vuxu.org \
    --to=meator@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).