[SOLVED] PKGBUILD review request

Ovsyanka · 2019-01-02 19:03:19

Hello!

I intend to make AUR package for online game, that releases as few binaries files. I readed the wiki about package building but it is my first time and I could mess something up. Could you check it and show me the right ways if I did something wrong?

# Maintainer: Igor Deyashkin <igor_deyawka@mail.ru>
pkgname="medivia"
pkgver="2.4.0"
pkgrel=1
pkgdesc="Client for medivia.online game server. This is mmorpg game based on Tibia."
arch=('i686' 'x86_64')
url="https://medivia.online"
# I am not sure what license is used
license=('unknown')
depends=('lib32-libglvnd')
source=("$pkgname-$pkgver.tar.gz::https://medivia.online/uploads/downloads/medivia-$pkgver-linux-32bits.tar.gz"
        "$pkgname.desktop")

# The archive does not containing root folder in it. I unextract it later on build stage into separate subfolder.
noextract=("$pkgname-$pkgver.tar.gz")

# autofill using updpkgsums
md5sums=('70a59bd2857a14256a6a20b3d00c0abd'
         '5808058b5bdea0b87199b34fe1dc1319')

build() {
    mkdir -p "$pkgname-$pkgver"
    tar -xzf "$pkgname-$pkgver.tar.gz" --directory "$pkgname-$pkgver"
}

package() {
    mkdir -p "$pkgdir/opt"
    mkdir -p "$pkgdir/usr/bin"

    cp -Rv "$srcdir/$pkgname-$pkgver" "$pkgdir/opt/$pkgname"

    install -Dm644 "$srcdir/$pkgname.desktop"    "$pkgdir/usr/share/applications/$pkgname.desktop"

    # I am not sure this is a good way
    ln -s "/opt/$pkgname/medivia" "$pkgdir/usr/bin/$pkgname"
}

And the namcap utility shows me the errors/warnings and I can't figure out what is serious and what I should just ignore:

medivia E: ELF files outside of a valid path ('opt/').
medivia W: ELF file ('opt/medivia/medivia') lacks FULL RELRO, check LDFLAGS.
medivia W: ELF file ('opt/medivia/medivia') lacks PIE.
medivia W: Directory (usr/bin) is empty
medivia E: unknown is not a common license (it's not in /usr/share/licenses/common/)
medivia E: Insecure RPATH './libs' in file ('opt/medivia/medivia')

Last edited by Ovsyanka (2019-01-02 22:49:28)

eschwartz · 2019-01-02 19:39:18

Ovsyanka wrote:

Hello!
I intend to make AUR package for online game, that releases as few binaries files. I readed the wiki about package building but it is my first time and I could mess something up. Could you check it and show me the right ways if I did something wrong?
# Maintainer: Igor Deyashkin <igor_deyawka@mail.ru>
pkgname="medivia"
pkgver="2.4.0"
pkgrel=1
pkgdesc="Client for medivia.online game server. This is mmorpg game based on Tibia."
arch=('i686' 'x86_64')
url="https://medivia.online"
# I am not sure what license is used
license=('unknown')

It probably makes sense to use "Proprietary" here, and install their EULA or Terms of Service to "$pkgdir/usr/share/licenses/$pkgname/ELUA"

depends=('lib32-libglvnd')
source=("$pkgname-$pkgver.tar.gz::https://medivia.online/uploads/downloads/medivia-$pkgver-linux-32bits.tar.gz"
        "$pkgname.desktop")

Since the application itself is prebuilt 32-bit software, the lib32-libglvnd dependency is specific to x86_64 arches. You should use depends_x86_64=('lib32-libglvnd').

Also does it not depend on libglvnd for i686 computers? Surely you should set depends_i686=('libglvnd') ?

# The archive does not containing root folder in it. I unextract it later on build stage into separate subfolder.
noextract=("$pkgname-$pkgver.tar.gz")

# autofill using updpkgsums
md5sums=('70a59bd2857a14256a6a20b3d00c0abd'
         '5808058b5bdea0b87199b34fe1dc1319')

build() {
    mkdir -p "$pkgname-$pkgver"
    tar -xzf "$pkgname-$pkgver.tar.gz" --directory "$pkgname-$pkgver"
}

Use bsdtar, since makepg itself guarantees that bsdtar exists, but GNU tar might not.

package() {
    mkdir -p "$pkgdir/opt"
    mkdir -p "$pkgdir/usr/bin"

    cp -Rv "$srcdir/$pkgname-$pkgver" "$pkgdir/opt/$pkgname"

    install -Dm644 "$srcdir/$pkgname.desktop"    "$pkgdir/usr/share/applications/$pkgname.desktop"

    # I am not sure this is a good way
    ln -s "/opt/$pkgname/medivia" "$pkgdir/usr/bin/$pkgname"
}

And the namcap utility shows me the errors/warnings and I can't figure out what is serious and what I should just ignore:

medivia E: ELF files outside of a valid path ('opt/').
medivia W: ELF file ('opt/medivia/medivia') lacks FULL RELRO, check LDFLAGS.
medivia W: ELF file ('opt/medivia/medivia') lacks PIE.
medivia W: Directory (usr/bin) is empty
medivia E: unknown is not a common license (it's not in /usr/share/licenses/common/)
medivia E: Insecure RPATH './libs' in file ('opt/medivia/medivia')

Okay, so about these warnings. The first three should be ignored, since you're using prebuilt proprietary programs you don't get to choose whether they are built using security hardening compiler flags. And /opt is exactly where prebuilt binaries should go. I assume it needs to locate game.wad and init.bc in the current directory of the program binary, which means using /opt.

The directory /usr/bin being empty is odd, did you actually use ln -s "/opt/$pkgname/medivia" "$pkgdir/usr/bin/$pkgname" in the version of the package that you checked with namcap or did you add that to the PKGBUILD later, but forget to rebuild the package with makepkg -f?

The license issue I mentioned above.

The insecure rpath seems to be quite pointless, since the binary does not actually depend on external libraries.

$ objdump -p medivia | grep NEEDED
  NEEDED               libpthread.so.0
  NEEDED               libdl.so.2
  NEEDED               librt.so.1
  NEEDED               libGL.so.1
  NEEDED               libm.so.6
  NEEDED               libc.so.6
  NEEDED               ld-linux.so.2

And it's not just pointless, it is absolutely wrong since ./libs will be relative to the current directory when running the program, not relative to the location of the binary. If you open a shell and run the program, or use the desktop file to start it, this will usually be looking in $HOME/libs/ which is... wrong. Deeply wrong.

Add a makedepends on the "chrpath" package and use chrpath -d to remove it from the binary.

Ovsyanka · 2019-01-02 20:37:06

Thank you for such fast and detailed answer!

eschwartz wrote:

It probably makes sense to use "Proprietary" here, and install their EULA or Terms of Service to "$pkgdir/usr/share/licenses/$pkgname/ELUA"

They don't have this in their archive. I'll request the license details from them, but is it OK to use the 'unknown' before I'll get it?

eschwartz wrote:

Since the application itself is prebuilt 32-bit software, the lib32-libglvnd dependency is specific to x86_64 arches. You should use depends_x86_64=('lib32-libglvnd').
Also does it not depend on libglvnd for i686 computers? Surely you should set depends_i686=('libglvnd') ?

I believe you are right. I got this dependency from output of the `namcap` and as I use x86_64 - It showed lib32-libglvnd. I will do what you suggested.

eschwartz wrote:

Use bsdtar, since makepg itself guarantees that bsdtar exists, but GNU tar might not.

Good point, I got it.

But I have additional question: How I suppose to knew about that? As I see, bsdtar is a part of libarchive package, that installed as dependency of the pacman package which included in base-devel group. It is qite a chain... Do I missing something. Is it good practice to rely on something that is not in the base-devel group, but installed just as dependency on the package which is in that group?

eschwartz wrote:

The directory /usr/bin being empty is odd, did you actually use ln -s "/opt/$pkgname/medivia" "$pkgdir/usr/bin/$pkgname" in the version of the package that you checked with namcap or did you add that to the PKGBUILD later, but forget to rebuild the package with makepkg -f?

Oops, you are perfectly right, I copied wrong output. But other output strings is actual.

eschwartz wrote:

And it's not just pointless, it is absolutely wrong since ./libs will be relative to the current directory when running the program, not relative to the location of the binary. If you open a shell and run the program, or use the desktop file to start it, this will usually be looking in $HOME/libs/ which is... wrong. Deeply wrong.
Add a makedepends on the "chrpath" package and use chrpath -d to remove it from the binary.

Okay, I added chrpath -d in the `prepare()` function. I readed https://www.archlinux.org/pacman/PKGBUILD.5.html and looks like my extracting operations shold be in the `prepare()` function too instead of `build()`. Am I right?

But could you explain or point me to the relevant information about next question? I am not familiar with that linking stuff at all. I tried to figure it out, but looks like it will took really a lot of time.
What this NEEDED entries actualy mean? If the program needed that files and looking for them in the ./libs directory - then it looks like nonsense because there is no such directory in the game folder. But the game works.. Does it mean that it actualy don't need that libraries and relations to them could be cutted off from the ELF file?

If you don't have time for that, could you just check if I made it right in the new version of PKGBUILD?

# Maintainer: Igor Deyashkin <igor_deyawka@mail.ru>
pkgname="medivia"
pkgver="2.4.0"
pkgrel=2
pkgdesc="Client for medivia.online game server. This is mmorpg game based on Tibia."
arch=('i686' 'x86_64')
url="https://medivia.online"
# I am not sure what license is used
license=('unknown')
depends_x86_64=('lib32-libglvnd')
depends_i686=('libglvnd')
makedepends=('chrpath')
source=("$pkgname-$pkgver.tar.gz::https://medivia.online/uploads/downloads/medivia-$pkgver-linux-32bits.tar.gz"
        "$pkgname.desktop")

# The archive does not containing root folder in it. I unextract it later on build stage into separate subfolder.
noextract=("$pkgname-$pkgver.tar.gz")

# autofill using updpkgsums
md5sums=('70a59bd2857a14256a6a20b3d00c0abd'
         '5808058b5bdea0b87199b34fe1dc1319')

prepare() {
    mkdir -p "$pkgname-$pkgver"
    bsdtar -xzf "$pkgname-$pkgver.tar.gz" -C "$pkgname-$pkgver"

    chrpath -d "$pkgname-$pkgver/medivia"
}

package() {
    mkdir -p "$pkgdir/opt"
    mkdir -p "$pkgdir/usr/bin"

    cp -Rv "$srcdir/$pkgname-$pkgver" "$pkgdir/opt/$pkgname"

    install -Dm644 "$srcdir/$pkgname.desktop"    "$pkgdir/usr/share/applications/$pkgname.desktop"

    # I am not sure this is a good way
    ln -s "/opt/$pkgname/medivia" "$pkgdir/usr/bin/$pkgname"
}

Thank you very much!

eschwartz · 2019-01-02 22:33:06

Ovsyanka wrote:

Thank you for such fast and detailed answer!
eschwartz wrote:
It probably makes sense to use "Proprietary" here, and install their EULA or Terms of Service to "$pkgdir/usr/share/licenses/$pkgname/ELUA"
They don't have this in their archive. I'll request the license details from them, but is it OK to use the 'unknown' before I'll get it?

I would personally consider it bad practice to upload a package for which people do not know the terms by which they can use it. But I bet they will probably respond with their terms of service fairly quickly.

Ovsyanka wrote:

eschwartz wrote:
Use bsdtar, since makepg itself guarantees that bsdtar exists, but GNU tar might not.
Good point, I got it.
But I have additional question: How I suppose to knew about that? As I see, bsdtar is a part of libarchive package, that installed as dependency of the pacman package which included in base-devel group. It is qite a chain... Do I missing something. Is it good practice to rely on something that is not in the base-devel group, but installed just as dependency on the package which is in that group?

It's probably not so obvious, mostly, because for most people it is sufficient to use the builtin extraction and they don't need to worry about doing it themselves. But since you're overriding it for nonstandard reasons, it became relevant.

The reason I specifically mentioned libarchive's bsdtar rather than GNU tar, is because bsdtar is what makepkg uses internally.

More generally I would feel comfortable relying on the recursive dependencies of base-devel. But there are differing opinions about whether that makes sense, so I do not make any guarantees that mine is the unbiased truth.

Ovsyanka wrote:

eschwartz wrote:
And it's not just pointless, it is absolutely wrong since ./libs will be relative to the current directory when running the program, not relative to the location of the binary. If you open a shell and run the program, or use the desktop file to start it, this will usually be looking in $HOME/libs/ which is... wrong. Deeply wrong.
Add a makedepends on the "chrpath" package and use chrpath -d to remove it from the binary.
Okay, I added chrpath -d in the `prepare()` function. I readed https://www.archlinux.org/pacman/PKGBUILD.5.html and looks like my extracting operations shold be in the `prepare()` function too instead of `build()`. Am I right?
But could you explain or point me to the relevant information about next question? I am not familiar with that linking stuff at all. I tried to figure it out, but looks like it will took really a lot of time.
What this NEEDED entries actualy mean? If the program needed that files and looking for them in the ./libs directory - then it looks like nonsense because there is no such directory in the game folder. But the game works.. Does it mean that it actualy don't need that libraries and relations to them could be cutted off from the ELF file?

Yes, you should use prepare for the bsdtar extraction -- this means if someone runs makepkg --noextract to rebuild the package, it won't bother re-extracting the sources. This also mimics what makepkg's own source extraction does. It is "more proper" to use the correct semantics, that is why we provide the flexibility of separate prepare, build, and package functions. That being said, the penalty for not using prepare() correctly is simply a wasteful extraction.

As for the NEEDED stuff, this is the output of a command that checks which shared libraries the binary requires. It doesn't say where the libraries come from, though, and of course the first place that the executable loader will look is in /usr/lib (or /usr/lib32 since this is 32-bit) -- and most of them (libc, libm, librt, libpthread, libdl) come from glibc, which is always available because more or less every single binary requires them, so you cannot have a working system without it (bash, pacman, systemd, the coreutils, among numerous others). Since this is a 32-bit binary, it actually depends on the 32-bit glibc libraries, but those are ultimately dependencies of lib32-libglvnd.

ld-linux.so.2 is... weird. That's the interpreter, it doesn't need to *link* to it at all. But I think we've indicated the developers of this game have weird binaries... it doesn't cause harm though, so it's not worth caring about a proprietary binary.

Finally, there is libGL.so.1 which is provided by lib32-libglvnd, which explains why you need that as a dependency.

Ovsyanka wrote:

If you don't have time for that, could you just check if I made it right in the new version of PKGBUILD?

# Maintainer: Igor Deyashkin <igor_deyawka@mail.ru>
pkgname="medivia"
pkgver="2.4.0"
pkgrel=2
pkgdesc="Client for medivia.online game server. This is mmorpg game based on Tibia."
arch=('i686' 'x86_64')
url="https://medivia.online"
# I am not sure what license is used
license=('unknown')
depends_x86_64=('lib32-libglvnd')
depends_i686=('libglvnd')
makedepends=('chrpath')
source=("$pkgname-$pkgver.tar.gz::https://medivia.online/uploads/downloads/medivia-$pkgver-linux-32bits.tar.gz"
        "$pkgname.desktop")

# The archive does not containing root folder in it. I unextract it later on build stage into separate subfolder.
noextract=("$pkgname-$pkgver.tar.gz")

# autofill using updpkgsums
md5sums=('70a59bd2857a14256a6a20b3d00c0abd'
         '5808058b5bdea0b87199b34fe1dc1319')

prepare() {
    mkdir -p "$pkgname-$pkgver"
    bsdtar -xzf "$pkgname-$pkgver.tar.gz" -C "$pkgname-$pkgver"

    chrpath -d "$pkgname-$pkgver/medivia"
}

package() {
    mkdir -p "$pkgdir/opt"
    mkdir -p "$pkgdir/usr/bin"

    cp -Rv "$srcdir/$pkgname-$pkgver" "$pkgdir/opt/$pkgname"

    install -Dm644 "$srcdir/$pkgname.desktop"    "$pkgdir/usr/share/applications/$pkgname.desktop"

    # I am not sure this is a good way
    ln -s "/opt/$pkgname/medivia" "$pkgdir/usr/bin/$pkgname"
}

Thank you very much!

That looks okay to me.

Last edited by eschwartz (2019-01-02 22:34:37)

Arch Linux

#1 2019-01-02 19:03:19

[SOLVED] PKGBUILD review request

#2 2019-01-02 19:39:18

Re: [SOLVED] PKGBUILD review request

#3 2019-01-02 20:37:06

Re: [SOLVED] PKGBUILD review request

#4 2019-01-02 22:33:06

Re: [SOLVED] PKGBUILD review request

Board footer