appimage, flatpak, rpm or archlinux aur #91
Comments
|
Flatpak is not viable for this app because of it's sandboxing behavior. AUR package, rpm package, any other package is up to community to contribute because I don't use these systems regularly and can't invest the time to figure out all the packaging specifics of each one. If someone wants to contribute, make sure you modify the build action to include the new artifact in the automatically generated releases. But I will look into appimage as it seems that it should work and is at least useful for wide variety of distros. |
|
I think flatpak is more work than appimage so. it is just that for flatpak I just use a command to update all of them. but appimage is not easy to update. btw I use that tremesof app and then added a folder with flatseal to access. so that sandbox is not that much of an issue. |
|
Ok, so I tried appimage and if I build it on older ubuntu then it packages in buggy webkitgtk which does not render properly. If I build it on newer ubuntu then it is less buggy but will not work on anything with older libs which defeats the portability of the appimage. So, for now, self compile it is for linux users. If anyone wants to experiment with appimage further, literally only change to enable it is to add "appimage" here |
qu1ck
changed the title
|
I am confused. I thought appimage was almost self-contained. so if I use new flatpak package on older os (like ubuntu 18) it would still work because it would take most of it libs and files from its own flatpak repo and not host. maybe I am missing something. |
|
No, it works with forward compatibility, even then, sometimes not. It almost never works in backwards direction. Appimage will not bundle your whole /usr/lib, it still relies on the fact that your client system will have compatible (which means same or newer) glibc, gtk and other core libs that make up the majority of GNU/Linux. Otherwise the image would be not 80mb but the size of half a linux distro. Appimage instructions directly advise to build on the oldest possible linux you can support so that everything newer has a good chance to work because for the most part linux tries to maintain strict backward compatibility in core libs. Unfortunately for TrguiNG even Ubuntu 20.02 which is not that old has buggy webkit so only viable appimage is from 22.04. Chances of it working on anything that is not quite recent are slim. I'll still include appimage with next release, maybe it will be useful for some. |
|
I think flatpak has more flexibility with respect to forward/backward versioning/compatibility. |
|
I don't see how that is technically possible, you either pack literally every lib and get a 1gb bundle or you don't have backward compatibility, those are the choices. Anyway, I added an appimage to the last release, it's built on ubuntu 22. |
thank you for the appimage. but about that
you can search the internet and see you answer about flatpak size. or this quote : |
|
Great, so flatpak does indeed bring a whole new OS (sans a kernel) with an app. At least it's smart enough to reuse the runtime between apps when it can. I looked more into building/publishing a flatpak and it's requirement for fully offline builds and lack of gnome 42 support which has libs needed for tauri introduces a whole host of issues. You can read more about it in tauri-apps/tauri#3619 and linked issues/discussions. Looks like this will have to wait until flatpak support is added to tauri (probably in tauri v2 which is currently in alpha). |
|
I explain to myself flatpak as kinda like docker. also having read this: This means that most AppImage bundles are not actually universal, and it gets harder to use them depending on the distribution you are using. If you are using a musl based distribution, the majority of AppImage bundles won’t work, because they need glibc. Likewise, if you use an immutable distribution, chances are they won’t come with many lower and higher level dependencies, because Flatpak already takes care of that. Flatpak is compatible in the majority of desktop cases. Even the Steam Deck uses Flatpak by default, because Flatpak ships with lower and higher level dependencies" as that piece is written by a person defending flatpak model I would assume flatpak has more deps packages in its bundle (or its equivalent). btw I use flatpak for some apps and it is useful. for example steam game store. it has a lot of lib32 deps and I didnt want them installed on my PC so I used flatpak. for a single app that usually doesnt need integration, flatpak may be too much and using an appimage for user is better. a good thing about flatpak (that I like) is that app setting and data are in just one folder and unlike other linux apps-systems , they are not scattered everywhere on my home folder. kinda like android but even better. I would recommend a appimage for users to download and test even if linux distributions later add this program, just so user can test this app before committing to installing it. but for long term distribution, I actually prefer flatpak as it would give a universal experience for all linux dists. if you are familiars with bottles app ( a wine env manager), its dev actually asked distro devs not to package its app in their repo and asks users to just use flatpak to install it. p.s. even steam deck uses flatpak as preferred way to install apps. |
|
I don't need more convincing that flatpak is useful and more universal. After doing the research about it I was already on the same page. Currently it's just too hard to package a tauri app into flatpak bundle and write an offline build recipe that one can upload to flathub. Unless I find a (relatively) easy to follow recipe for tauri v1 we will have to wait until tauri v2 and native flatpak support. |
|
oh. hope you are successful with build later. |
|
Note to self: this is a tauri project on flathub that I should be able to model flatpak build after. |
|
I have never done it, and I don't know if I can. But if nobody else is interested, I might be able to attempt to assist with the AUR. It would be interesting to learn the pkgbuild system. I already have an arch package that was created from your .deb which lists dependencies, etc. Of course, if anybody who has experience is interested in doing this, it would be better. but if not, I can try. |
|
This is my first attempt. This file successfully built and created the package for Arch on my system. rezad, can you test this pkgbuild on your system? download it and remove the .txt extension, and then use the command makepkg. let me know what happens. |
|
The app is now on flathub https://flathub.org/apps/org.openscopeproject.TrguiNG |
|
qu1ck - the one thing that won't work well is the desktop file. the app.desktop file in the src-tauri folder is pretty much blank. Is there any way you can incorporate the desktop file that we discussed here in place of the blank one to facilitate a more seamless desktop experience for the end user? |
|
You can get full desktop file from here Few notes on your pkgbuild:
|
|
OK, definitely do NOT use my PKGBUILD. it crashed my system. i'll try to figure out what's wrong. |
in span of five hours. |
|
Userspace program should not be able to crash your system. I doubt whatever caused your crash is directly caused by you misconfiguring the package, at best it just exposed a hidden problem that was already there. |
yeah. |
|
As a non-developer, this is a huge learning experience for me. It didn't mess the entire system up per se, but it did really mess up Cinnamon. I believe the problem was related to some missing "" around the install command parameters. Anyway, this is my second version. I have changed the license, changed the source for the db as you suggested, and changed the permissions (which definitely were an issue). I have not yet worked on the .desktop file issue. That will be next. But this should be good for anybody who wants to test it on an arch-based system. |
|
OK, here it is. a working package for Arch. I am now running this package instead of the manually cloned repository, saving me several GBs of space in my home directory. Download the pkgbuild file, take out the .txt extension, put it in a folder, and run: makepkg I will try to see if I can figure out how to submit it to the AUR. I'm sure, being my first pkgbuild, that there'll be a hundred different opinions about ways that it could have been done better...but that's OK. |
|
The AUR is now operational. The package is here. |
|
Great, thanks for working on this. I gave it my vote :) We should probably automate releases to update the AUR repo, there is a convenient github action for that https://github.com/marketplace/actions/publish-aur-package Can you add me as maintainer on AUR? My username/email are same as on github. |
|
I think I did it. My pleasure. As I said, it was a great learning experience. i'll look into this automation next week unless you get to it first. |
No need, the action requires ssh key saved as secret in github, only I will be able to do that. That's also why I asked to be added as maintainer, so I could use my ssh key. |
That file will be autogenerated for each new version and it's not really intended to be viewed by humans anyway so it doesn't matter.
Have you clicked the |
LOL. Missed that.... :-) |
OK, makes sense. I was just following the archwiki for headers on the top. |
|
Perhaps i should figure out how to get the pkgbuild to clean up after itself - delete the git folder that's created to save over 2GB. No reason for a 17MB program to take up 2.2GB. |
|
FYI, I updated the pkgbuild in the aur with some technical fixes. it will now provide the latest release version, as opposed to the latest commit. If you'd like, I could possibly make a second one that provides the latest build as a -git package, development-type package. If you would apply the same type of automation to such a package, it perhaps could be updated automatically every time you apply a new commit. |
|
I just added automation to update AUR repo when new version is released. We'll see how well it works when next release happens, I tested it as far as I could without pushing bogus updates to the actual repo.
I don't know if there is user demand for this, if you want to add it - go for it. But it should not require automation, probably just remove sha sums checking (if it is allowed) and use "latest" instead of tag in the dbip url. It should just work. |
Right, removing the sha sums would not work, but it wouldn't affect anything, because the only differences would be in the git repository, (not the download of the dbip or the desktop file) and the git repository's sha sum is "SKIP". In order to get the latest, we just take away the version number completely from the source command and it will automatically clone the latest master. [in the main package, the package has a relative version number in the sources command; when you bump to 1.1.0, for example, that line in the sources command doesn't need to be changed; only the pkgver field needs to be changed.] However, we would need to change the pkgbuild slightly so that it would trigger an update. In this case, I believe we would change pkgrel field from 1 to 2, and then to 3 for however many commits there are. However, you may be right about the demand, and even if we decide to do this, we should probably ensure first that the automation is working properly in the main package. |
|
No, pkgrel is for packaging version only, when software itself changes the version should be updated. That's how version in dev builds works too, it looks like |
|
Just published v1.1.0, the AUR update job seems to work correctly. @username227 can you verify that build still works on arch? |
|
Just tested. Worked like a charm. Great job! |
|
Great, so now this issue is just about rpm. Any fedora aficionados who would like to pitch in? |
|
I just added npm as a depencency and changed the pkgrel to 2. Please update on your end if necessary. |
|
It is not needed at runtime and you already have node which ships with npm in makedepends so the change is redundant. |
|
nodejs has npm as an optdepends, not makedepends |
|
Ok, then add it to makedepends, not depends. |
|
yes, that's what I did since you confirmed it's not needed at runtime, which I suspected. Thanks! |
|
error log |
|
Honestly I can't help much with debugging that build failure because I don't have arch. It complains about being unable to link something from libdbus even though the lib seems to be there. Possible reasons I can think of:
What does |
it outputs: |
|
As it should, so the lib is there and build system knows how to find it, I'm not sure why it is not on linker the command line. But absolutely nothing in the app code changed between v1.1 and 1.2, not even lib versions. So it must be rust version, gcc version or some other change. |
|
The program compiles just fine when I do it manually. Only the script doesn't work. The only differences I can tell in the script are that it has "npm ci" instead of "npm install", but changing that didn't make a difference. |
|
Neither of those are what caused the failure. Probably just dbus is missing as dependency in the script.
I simply mirrored the mmdb file from db-ip.com to release page in this repo because old db files tend to disappear from the original website making old links invalid. |
How do I add this flag? does it go on the "npm run build -- -b" line like this:?? |
|
No, that won't work. You probably can add it through defining RUSTFLAGS env variable but you shouldn't have to manually add it, as you say yourself, the manual build works, that means there is some difference in how script environment is setup. Did you try to add dbus to dependencies in the PKGBUILD? |
|
yes, adding dbus as a dependency didn't make a difference. I checked the diff's between the old pkgbuild and the new one...there's absolutely no reason I can think of why it should work when I do it manually but not when I do it through the pkgbuild. I am stumped. Have to get to work though. Will try to look again later. Hopefully in the interim someone on the aur will yell at us that the pkg is broken and tell us the reason...lol. |
|
OK, reddit to the rescue. It appears that it won't link properly with LTO enabled. Using options=('!lto') in the package build seems to solve the problem. Not sure why it worked until now, but whatever. Before I push out a correction on the AUR, someone claimed that git is missing from makedepends. Should I add this? I wanted your input to see if it was necessary or if it's redundant. |
|
Yes, rust uses git to checkout some libs. Can you open a PR with the changes for the template here? https://github.com/openscopeproject/TrguiNG/blob/master/ci/generate_pkgbuild.py |
Sure, i'll work on that. |
|
I made a git pkgbuild. I installed it for myself. I am hoping it will auto-update when you make another commit, but i'm not sure. I'll keep an eye out. If it works, I could theoretically publish it. We would just have to make the git version contra to the regular one and vice-versa. |
|
just sharing that everything seems to have worked absolutely flawlessly for the arch package in the latest update! |
I wanted to try this app but it doesn't have a x64 version of bianry for linux (not a deb one).
maybe a flatpak or an appimage would help users like me.
The text was updated successfully, but these errors were encountered: