Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Linux re-packaging compatibility #554

Open
tinywrkb opened this issue May 14, 2020 · 3 comments
Open

Better Linux re-packaging compatibility #554

tinywrkb opened this issue May 14, 2020 · 3 comments
Labels
type: enhancement Proposed improvement

Comments

@tinywrkb
Copy link

tinywrkb commented May 14, 2020

There are a few issues that prevent re-packaging and distributing Arduino Create Agent through repositories instead of the current binary installer.

There are blocking issues that prevent re-packaging:

  • No tarball release.
    The binary installer, even with the --mode unattended still tries to run Arduino_Create_Bridge after the installation and it does not respect --prefix.
  • Executable and config in the same folder limitation.
    The app should look for the config at $XDG_CONFIG_HOME/arduino-create/ with $HOME/.config/arduino-create/ as a fallback if $XDG_CONFIG_HOME is unset or empty. See XDG Base Directory Specification

Would be nice to have:

  • Instead of $HOME/.arduino-create/ use $XDG_DATA_HOME/arduino-create/ with $HOME/.local/share/arduino-create/ as a fallback if $XDG_DATA_HOME is unset or empty.
  • In case that config.ini does not exist in the config folder, create a default config file.
  • A single app for both Chrome and Firefox. The current Linux installers are actually the same for both Chrome and Firefox, I don't know if this is intentional.

For my own needs, and as a POC, I packaged the Create Agent as a Flatpak here. Notice the ugly workaround in the startup script, copying the executable to the config folder.

@tinywrkb tinywrkb changed the title Better Linux re-packaing compatibility Better Linux re-packaging compatibility Jun 16, 2020
@umbynos umbynos added the type: enhancement Proposed improvement label Nov 6, 2020
@umbynos
Copy link
Contributor

umbynos commented Nov 6, 2020

Hello! Thanks for the interest in the project!
At the moment we are in the middle of a lift & shift process regarding the CI/CD pipeline to generate the installers. We will for sure consider the POC you made in the near future.

@tinywrkb
Copy link
Author

tinywrkb commented Nov 7, 2020

@umbynos, thank you for your reply. I hope that you won't only make it easy for package maintainers to re-package the app but also consider distribution via Flathub as a Flatpak app.

@tinywrkb
Copy link
Author

tinywrkb commented Apr 8, 2021

Any news about this?

Can we at least get a binary tarball release? The installer needs access to /proc/self/exe and due to the security implications of having such access, it's not available during the Flatpak installation/apply_extra step as Flatpak is running as the root user.
I'm seeing a failed readlink(/proc/self/exe) and the installer.
I can go around this issue by installing to the user Flatpak installation and not system-wide but that's not a proper solution.

Also, please consider officially distribute this app via Flathub.

Note that I'm not that sure about certificate handling. I guess maybe bind-mount ~/.pki/nss from the host, package certutil, and add support in the app for adding certificate via certutil.
I should also add that IIRC correctly Firefox already support the XDG dirs specification for the certs DB while Chrome/Chromium doesn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

2 participants