4 ms·

I found it a more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" sy

by iotku 3y ago

I found it a more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" system anyways) Similar (perhaps slightly lower given verification efforts) concerns about integrity/supply chain (who is maintaining this package really? Is it a clean build from the correct source?), but distro independent and often works good enough with some exceptions. Sandboxing is limited but better than nothing. Once I somewhat understood the process and where everything is on GitHub (fairly transparent with CI stuff) I felt a bit more comfortable with things, but a lot of the store interfaces leave a lot of questions unanswered about the source (location) of the software. If something is out of date I can usually make a GitHub issue and it'll get sorted soon enough. Not the worst experience I've had.

yjftsjthsd-h 3y ago
> more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" system anyways) The AUR package would still use less disk/network since the flatpak is carrying around effectively its own distro / base image layers. OTOH no sandbox so weigh as you will.
forgotpwd16 3y ago
>which don't have any benefit of being a part of a "build" system anyways Building a package doesn't imply compilation of the binaries the package is composed from. Packages are meant to provide easier distribution and maintenance.
- iotku 3y ago
  I don't particularly disagree, but rather I've viewed the AUR as having value in that you can change build options (for instance enabling/disabling features) that may not exist in pre-existing binary builds. The distribution aspect of the AUR is useful given the various tooling/helper utilities around it, but I don't see it as more effective than flatpak if you're just using binaries that already exist. While the AUR is a bit more of a direct path, you don't have to worry about system level dependencies changing and breaking the binaries with flatpak (even if that does result in more disk usage as a side-effect).

by iotku 3y ago

yjftsjthsd-h 3y ago

> more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" system anyways) The AUR package would still use less disk/network since the flatpak is carrying around effectively its own distro / base image layers. OTOH no sandbox so weigh as you will.

forgotpwd16 3y ago

>which don't have any benefit of being a part of a "build" system anyways Building a package doesn't imply compilation of the binaries the package is composed from. Packages are meant to provide easier distribution and maintenance.

iotku 3y ago
I don't particularly disagree, but rather I've viewed the AUR as having value in that you can change build options (for instance enabling/disabling features) that may not exist in pre-existing binary builds. The distribution aspect of the AUR is useful given the various tooling/helper utilities around it, but I don't see it as more effective than flatpak if you're just using binaries that already exist. While the AUR is a bit more of a direct path, you don't have to worry about system level dependencies changing and breaking the binaries with flatpak (even if that does result in more disk usage as a side-effect).