Package Details: solarwallet-appimage 0.25.3-2

Git Clone URL: https://aur.archlinux.org/solarwallet-appimage.git (read-only, click to copy)
Package Base: solarwallet-appimage
Description: Wallet for the Stellar payment network by SatoshiPay (AppImage)
Upstream URL: https://solarwallet.io/
Licenses: MIT
Conflicts: solarwallet
Provides: solarwallet
Submitter: chrpinedo
Maintainer: chrpinedo (yochananmarqos)
Last Packager: yochananmarqos
Votes: 0
Popularity: 0.000000
First Submitted: 2020-05-08 14:50
Last Updated: 2020-08-05 14:54

Latest Comments

chrpinedo commented on 2020-05-13 20:05

Hi yochananmarqos! I did the same and I added you as comaintainer for this package.

(Regarding the electron package, I found this wiki page https://wiki.archlinux.org/index.php/Electron_package_guidelines with details about how to package electron apps but I couldn't build the package with the system electron package)

yochananmarqos commented on 2020-05-13 14:26

I added you as a Co-Maintainer for solarwallet if you want to change it to use the system Electron.

chrpinedo commented on 2020-05-13 06:33

I changed the description to be similar to your package.

Regarding your question, if "I would have created this package at all if I had found yours first", sure, I wouldn't have created this one. But once I created it and I realized of the huge different size of the 2 uncompressed packages (90 MB vs 280 MB), if both packages have the same functionality with different size, I prefer to use the one that is smaller.

In fact, IMHO there could be two packages:

  • electron files' package, which would be compiled against the electron package of ArchWiki to reduce the size of this package.
  • AppImage package, which should be bigger than the previous one, which doesn't depend on electron ArchWiki package

So, users can choose to use the electron package because they have more electron applications on their systems or they can choose to use the AppImage package because it is their unique electron application in their system or because they want to run the application with the electron version of the upstream (avoid any compatibility problem among electron versions).

In any case, this is not a issue of "my" packet vs "your" package. If you want, I can co-maintain or totally delegate this package to you. Perhaps it is easier if the two packages are maintained by the same person.

Regards!

yochananmarqos commented on 2020-05-12 22:50

I suppose the real question is: Would you have created this package at all if you had found mine first? ;)

I used the description from the Debian control file since it's more descriptive.

Oops, they changed their license when I wasn't looking. Done.

A package already provides and conflicts with itself, nothing needs to be done for either package.

chrpinedo commented on 2020-05-12 20:16

In any case, for the moment, we could maintain the two versions in AUR and then decide depending on the use of the packages, perhaps the AppImage package is senseless.

For now, It would be a good idea to provide some consistency between the two packages:

  • name is ok: solarwallet & solarwallet-appimage
  • description: I would suggest to have the same description and in my case adding at the end " (AppImage built from software)". This is the method that is is used for "freecad" and "freecad-appimage" packages.
  • license: MIT (you are wrong with GPL3)
  • add the "provides" and "conflicts" keywords with "solarwallet". So only one version can be installed by users to avoid problems.

What do you think?

yochananmarqos commented on 2020-05-12 19:58

I see, makes sense. When I saw this package added, I realized I should rename my package to match upstream and this package. They made some changes upstream awhile back and I had forgotten to match.

If I decide to switch to using the system Electron instead of the bundled one, I'll let you know.

chrpinedo commented on 2020-05-12 19:55

Firstly, I created this aur package because i didn't find "Solar Wallet" in AUR.

When I began compiling Solar Wallet my idea was to use electron files not the AppImage, however some issues made me change my original idea:

  • It seems that under electron/dist/linux-unpacked path there quite rubish to delete. You deleted some stuff in your package I didn't realize when I performed my tests (files for other platforms) but there are still warnings produced by makepkg because source files are included in the final package: Makefiles, config.status....

  • The size of the uncompressed package (your package) is about 280MB whereas the size of the uncompressed appimage is about 90MB. Perhaps the size could be reduced if solarwallet package would be compiled against the electron8 package of ArchLinux. However, I don't know how to to do it.

So, the size of the package (and my lack of knowledge of how to build agains the electron package of ArchLinux) is the main reason I decided to use the AppImage.

Since, the AppImage is not directly provided by the upstreamer AFAIK, I need to build it from software.

yochananmarqos commented on 2020-05-12 16:30

What's the point in building it from source to install an AppImage? I already have a package building from source, solarwallet (just renamed it from satoshipay-stellar-wallet).