PKGBUILD for source file which is already an ARCH package

m1ke.v4n.dyke · 2018-09-06 13:10:57

Hi everybody,

I would like to create a AUR Package for everdo (as their download page is well hidden).
They only provide an ARCH package, which can simply be downloaded and installed via 'pacman -U ...'.

Is there a general approach for creating AUR packages for ready to be installed packages? Or is there some way to tell in the PKGBUILD that makepkg only has to run 'pacman -U' on the downloaded source file (didn't find anything on that in the wiki).

Thanks in advance,

Mike

Awebb · 2018-09-06 13:37:40

You don't. In this case, they do not publish a link, but require you to get in touch with them via email. I do not think they'd appreciate an AUR package. I'd get in contact with them before you push their private links to a public repository.

EDIT: I don't see why you would want an AUR package that installs a complete tarball.

Last edited by Awebb (2018-09-06 13:39:45)

Trilby · 2018-09-06 13:51:41

To elaborate on the above, a PKGBUILD is a recipe for makepkg to make a package that can be installed with `pacman -U`. If you already have a package that can be installed with `pacman -U`, you don't need to use makepkg and thus you don't need a PKGBUILD. Just install the package (assuming you trust where it came from).

m1ke.v4n.dyke · 2018-09-06 14:07:32

Awebb wrote:

You don't. In this case, they do not publish a link, but require you to get in touch with them via email. I do not think they'd appreciate an AUR package. I'd get in contact with them before you push their private links to a public repository.
EDIT: I don't see why you would want an AUR package that installs a complete tarball.

In this thread of their forum are some comments that they tried providing an AUR package. I thought that I might help out, if there is a solution to this post.
The "problem" is that their build system automatically provides the arch linux package. So I thought it would have been easiest if one can use that package in the PKGBUILD.

Last edited by m1ke.v4n.dyke (2018-09-06 14:08:13)

Trilby · 2018-09-06 14:41:00

Yes, it would be ideal to build this with a proper PKGBUILD (and the fact that the upstream authors think it is such an impenetrable topic is really discouraging - do they know what they're doing).

But to make a proper PKGBUILD, you would nee *much* more cooperation from upstream than they seem willing to provide. You'd need the source code and and build steps they are currently using. They don't seem interested in sharing either of these.

It doesn't make any sense to make a PKGBUILD to repackage a built package (strictly speaking it is possible, but it would be completely silly and would not likely result in anything better than the already built package).

progandy · 2018-09-06 14:52:48

Trilby, upstream uses electron builder, so they only know javascript. It seems that this monstrosity automates packaging and hides the details from the user.
It looks like they want to use the AUR to advertise their product, but not provide sources.

Last edited by progandy (2018-09-06 14:54:55)

eschwartz · 2018-09-06 15:03:51

The link from the forum site, downloads a .pacman file, which is a renamed .pkg.tar.xz generated by https://github.com/jordansissel/fpm

It contains gems such as

pkgdesc = 
  The Perfect App for GTD / Getting Things Done

What is this newline???

This is the install script

post_install() {
    :
#!/bin/bash

# Link to the binary
ln -sf '/opt/Everdo/everdo' '/usr/local/bin/everdo'

}
post_remove() {
    :
#!/bin/bash

# Delete the link to the binary
rm -f '/usr/local/bin/everdo'

}

I would argue that in some cases, it is indeed better to create a PKGBUILD and do the package properly, treating this as a tarball containing a proprietary vendor-neutral binary.

Moreso, as this is an electron app and should use the system electron.

depends=('electron')

package() {
    install -Dm644 "${srcdir}"/opt/Everdo/resources/app.asar \
        "${pkgdir}"/usr/lib/everdo.asar

    cp -r "${srcdir}"/usr/share "${pkgdir}"/usr/
    sed -i 's@/opt/Everdo/everdo@everdo@' "${pkgdir}"/usr/share/applications/everdo.desktop

    cat << '__EOF__' | install -D755 /dev/stdin "${pkgdir}"/usr/bin/everdo
#!/bin/sh

exec electron /usr/lib/everdo.asar "$@"
__EOF__
}

You may need to rebuild one open-source ELF library from inside the asar archive against the system electron version: node_modules/sqlite3/lib/binding/electron-v2.0-linux-x64/node_sqlite3.node

However, I think it may simply be binary-compatible with multiple electron versions... apparently Electron are trying to be better about this.

Last edited by eschwartz (2018-09-06 23:44:02)

Trilby · 2018-09-06 23:17:11

Eschwartz wrote:

I would argue that in some cases, it is indeed better to create a PKGBUILD and do the package properly, treating this as a tarball containing a proprietary vendor-neutral binary.

I agree if we assume it is worth packaging at all. Given all these oddities, I'd certainly not want to use it. But I suppose if others do, I'd only offer the thought that a turd wrapped in a pretty gift wrap will still stink.

eschwartz · 2018-09-06 23:52:51

Trilby wrote:

Eschwartz wrote:
I would argue that in some cases, it is indeed better to create a PKGBUILD and do the package properly, treating this as a tarball containing a proprietary vendor-neutral binary.
I agree if we assume it is worth packaging at all. Given all these oddities, I'd certainly not want to use it. But I suppose if others do, I'd only offer the thought that a turd wrapped in a pretty gift wrap will still stink.

Distribution packaging can be challenging to people who don't even use the distro at all, and aren't actually running Arch in order to create packages.

In this case, the root of the problem is, mostly, using fpm, since fpm is the thing which created the nastiness in question: https://github.com/jordansissel/fpm/blo … NSTALL.erb
Can't really blame the everdo developer for the ugly .INSTALL formatting, can blame him for the unpackaged symlinks...

(Yes, I spend way too much time looking up this uselessly horrifying information.)

...

Honestly, you're missing the forest for the trees.

The everdo developer committed a much more basic, horrifying sin: he became a nodejs programmer and wrote an electron app.

Trilby · 2018-09-06 23:59:30

Eschwartz wrote:

In this case, the root of the problem is, mostly, using fpm

All the electron stuff is greek to me (worse actually, I can decipher common word roots with greek origins at least). But I gather there are decent ways to provide the source material for electron apps so they can be packaged by those who do understand a given distro's packaging. Failing to do this is what I think is the root of the problem. Sure, use fpm, or whatever, if you want, and provide that odd .pacman file if you want, but also give users of other distros the material they need to do things right.

I certainly don't expect upstream developers to package for different distros - in fact attempting to do so when they shouldn't is the source of many needless headaches. I only expect them to not get in the way of competent packagers.

Is this software proprietary / closed-source? Is that why such information hasn't been provided?

eschwartz · 2018-09-07 00:31:47

Given the developer asks you to provide your email in order to receive the download link? Probably...

The fpm-generated metadata simply says "license = unknown" but that may be cluelessness. Still, when in doubt and no license is specified, it's definitely not free even if the source code is available... which this isn't because it is one single heavily obfuscated and minimized bundle.js javascript app (plus open-source dependencies from the nodejs registry, plus electron itself).

Arch Linux

#1 2018-09-06 13:10:57

PKGBUILD for source file which is already an ARCH package

#2 2018-09-06 13:37:40

Re: PKGBUILD for source file which is already an ARCH package

#3 2018-09-06 13:51:41

Re: PKGBUILD for source file which is already an ARCH package

#4 2018-09-06 14:07:32

Re: PKGBUILD for source file which is already an ARCH package

#5 2018-09-06 14:41:00

Re: PKGBUILD for source file which is already an ARCH package

#6 2018-09-06 14:52:48

Re: PKGBUILD for source file which is already an ARCH package

#7 2018-09-06 15:03:51

Re: PKGBUILD for source file which is already an ARCH package

#8 2018-09-06 23:17:11

Re: PKGBUILD for source file which is already an ARCH package

#9 2018-09-06 23:52:51

Re: PKGBUILD for source file which is already an ARCH package

#10 2018-09-06 23:59:30

Re: PKGBUILD for source file which is already an ARCH package

#11 2018-09-07 00:31:47

Re: PKGBUILD for source file which is already an ARCH package

Board footer