Arch Linux User Repository

Looks like it installed correctly for me. Well done, @gameslayer!

@xiota actually not true, while I use it for my own personal software I would love to have other devs use it also, as for security I update it pretty regularly and they get the same patches and updates Chromium gets since it again uses Chromium's web engine technology and is open source.

Except it isn't in any broken state also that wouldn't be right as that would completely break it as the path in the fakeroot would be /pkg/libelectron/opt/libelectron/libelectron and the app wouldn't be able to find electron which would result in the error sh: line 1: electron: command not found so why would I do this when the way I have done it is correct and works?

once it runs ./setup it npm will create the node_modules folder in $srcdir and then it will move that to "$pkgdir/opt/libelectron". If you aren't using the normal standard build environment aka makepkg that Arch uses and recommends which is apart of pacman then that is on you.

@Alkaris @Bitals Don't bother with this package. In addition to poor packaging, it's used only for the maintainers' personal apps, which use electron as a web browser to navigate the official websites. Electron used this way is not secure. As much as you may want dedicated apps, you're better off using plain web browsers.

I can't believe how much of a mess this package was to build, all because of this one stupid line;

cp -r $srcdir/libelectron/node_modules "$pkgdir/opt/libelectron"

by correcting it to;

cp -r $srcdir/libelectron "$pkgdir/opt/libelectron"

That's literally all you had to do. That easy of a fix to make this install. Don't just assume the directory environment is going to be the same as your weird ass setup. Don't traverse extra directories that may or may not exist before creating beforehand, and in this case example being cp -r $srcdir/libelectron/node_modules just don't do this because the package hasn't built itself yet and created the directories it needs.

It's just not configurable by PKGBUILD. Look, I build this very package the wiki way, aka git clone and manually run makepkg:

> grep BUILDDIR /etc/makepkg.conf
BUILDDIR=~/GitClonedRepos/This\ dir\ ha\ a\ lot\ of\ spaces
> makepkg -sf
==> Making package: libelectron 1.0.17-1 (Mon 18 Dec 2023 20:20:30 +04)
...
cp: cannot stat '/home/bitals/GitClonedRepos/This': No such file or directory
cp: cannot stat 'dir': No such file or directory
cp: cannot stat 'ha': No such file or directory
cp: cannot stat 'a': No such file or directory
cp: cannot stat 'lot': No such file or directory
cp: cannot stat 'of': No such file or directory
cp: cannot stat 'spaces/libelectron/src/libelectron/node_modules': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...
makepkg -sf  31.67s user 14.49s system 128% cpu 35.793 total
> ll -ah ~/GitClonedRepos/This\ dir\ ha\ a\ lot\ of\ spaces/libelectron/    
total 0
drwxr-xr-x 1 bitals bitals 12 Dec 18 20:20 .
drwxr-xr-x 1 bitals bitals 50 Dec 18 20:20 ..
drwxr-xr-x 1 bitals bitals 22 Dec 18 20:20 pkg
drwxr-xr-x 1 bitals bitals 78 Dec 18 20:20 src

But it builds completely fine if I quote $srcdir. Granted I edited the makepkg config, but just to quickly simulate a problem. There might be an AUR helper somewhere written by somebody insane, or just an insane user (far more likely). Or Manjaro will do this by default because it can, I won't be surprised honestly. You do not control the user environment. Encasing variables containing paths in quotes is just a foolproof best practice, I don't understand your struggle to avoid doing so.

@gameslayer it does not contain spaces on your system, but it might on someone else's. It's a configurable absolute path. You can not set it in PKGBUILD, it's configurable by an AUR client, by user and so on. You only control the last directory in that path, but not any of the parents.

I can because I made this package and control how it builds and installed based on how the pkgbuild file works.