Install .deb and .rpm button

[Dvlv]

• Add button alongside the Open Terminal list to "Install Deb" or "Install RPM" based on the detected distro

  • Requires list of distros which support deb / rpm in utils.rs

• This will require host access

  • Check if I can add xdg-download access without tripping Flathub's linter

• Look into if I can add a right-click option in Nautilus for deb/rpm with "Install in " options.

[VortexAcherontic]

I believe Nautilus to have two way of adding context menus.
One are shell script typically located at: $HOME/.local/share/nautilus/scripts but those will show up in a dedicated menu "Scripts".

Additionally nautilus provides a way of adding python script for a little more richer presence of context entries at $HOME/.local/share/nautilus-python which is what some gnome extensions use.

The later will require the user to also have some extra nautilus plugin/extension installed. I once ran into this on openSUSE Aeon which did not had this package. But I do not recall the name atm.

But I know of protontricks, available at flathub, which has a dedicated entry for EXE files to run them inside a Proton prefix in Steam. But not sure how they do it.

[Dvlv]

TODO

• Documentation
  • deb/prm functionality
  • Swap GNOME console and terminal
  • Mention flatpak sandbox only has access to Downloads
  • Nautilus right-click

[Dvlv]

I think this feature is now ready, if anyone is reading this and wants to test out the master branch, please do!

[VortexAcherontic]

While testing this I came across little nuances. The feature onto it's own worked fine 👍️ This is more of a discussion for any improvements to the feature in future revisions.

Multi select: Some can only select one file at once. But it might be that the user might need to install 2 or 3 packages in the same run because a depends on b and that depends on c. While this is perfectly possible in it's current stage it also would require the user to run the "install dep/rpm" process multiple times.

File filters It feel like adding file filters to the FileDialog might be a good idea as of now you can select an RPM to be installed as a DEP and vise versa, or just any file tbf. Not that it would cause any damage because either zypper, dnf or apt will just stop and the terminal window will close.

APT choosing repo version over downloaded package While installing the chrome dep I noticed: Note, selecting 'google-chrome-stable' instead of '/home/vortexacherontic/Downloads/google-chrome-stable_current_amd64.deb' Not sure if this is an APT default and we might keep this behavior or if there is any command line argument to favor the local package over the repository? Especially considering Debian has a "stable" package base which might result in APT installing an older app from the repos instead of the possibly more recent one the user might have downloaded?

Tbh I currently lack some proprietary RPMs and DEPs to test which probably do not have a equivalent in the default repos of the distributions.

Import GPG Keys Furthermore I noticed that, at least for zypper, will show a red warning if the RPM is not signed and/or the GPG Key is missing. The user can progress form there with no issues as they get ask how to proceed. Means the feature is not broken. I was thinking if in some v2 of this feature we might also try on adding an import key feature?

[Dvlv]

Multi Select

I don't think I've ever had to do this, so I don't think it's worth the extra code-complexity.

File Filters

There are already filters, which work for me on Fedora, but I guess I should also check the file extensions too.

APT choosing repo version over downloaded package

There is no google-chrome-stable in Debian's repos, I think the warning is just confusing: https://unix.stackexchange.com/questions/542980/apt-install-note-selecting-foo-instead-of-foo-x-y-z-amd64-deb-what-it

Import GPG Keys

Beware of scope-creep, BoxBuddy is a UI for Distrobox, not a package manager. Messing with GPG Keys feels too low-level, and I'm happy to leave that to be done in a terminal

(A software store which uses Distrobox behind-the-scenes is something I've envisioned, but I'm not sure how I'd handle all the mirrors and stuff).

[VortexAcherontic]

(A software store which uses Distrobox behind-the-scenes is something I've envisioned, but I'm not sure how I'd handle all the mirrors and stuff).

Yesterday I was thinking about something similar for BoxBuddy a very simple package managing ui which only consist of a search field. Then it would use the package manager of the container to pass the string from the ui to the container and fetches the output.

Somehow like this:

1) User searches for "firefox" 2) Then run from the UI in the background: distrobox-enter -n tumbleweed -- zypper se -s firefox 3) Receive output like:

Repository 'Java:Factory' is out-of-date. You can run 'zypper refresh' as root to update it.
Repository 'openSUSE-Tumbleweed-Non-Oss' is out-of-date. You can run 'zypper refresh' as root to update it.
Repository 'openSUSE-Tumbleweed-Oss' is out-of-date. You can run 'zypper refresh' as root to update it.
Loading repository data...
Reading installed packages...

S | Name                               | Type    | Version     | Arch   | Repository
--+------------------------------------+---------+-------------+--------+------------------------
  | eid-mw-firefox                     | package | 5.1.11-1.3  | x86_64 | openSUSE-Tumbleweed-Oss
  | firefox-esr-branding-openSUSE      | package | 68-4.1      | x86_64 | openSUSE-Tumbleweed-Oss
  | firefox-uget-integrator            | package | 1.0.0-2.13  | x86_64 | openSUSE-Tumbleweed-Oss
  | MozillaFirefox                     | package | 121.0.1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
  | MozillaFirefox-branding-openSUSE   | package | 68-4.1      | x86_64 | openSUSE-Tumbleweed-Oss
  | MozillaFirefox-branding-upstream   | package | 121.0.1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
  | MozillaFirefox-devel               | package | 121.0.1-1.1 | noarch | openSUSE-Tumbleweed-Oss
  | MozillaFirefox-translations-common | package | 121.0.1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
  | MozillaFirefox-translations-other  | package | 121.0.1-1.1 | x86_64 | openSUSE-Tumbleweed-Oss

4) Parse the output of the search command and present each package in a list where the user can then install or uninstall the software. 5) Which then would issue the install / remove command of the package manager like distrobox-enter -n tumbleweed -- sudo zypper in --no-confirm MozillaFirefox

But the main challenge would be, that each package manager, eg. apt, zypper, dnf, pacman ... have different outputs and some might show in the search output if a software is installed and some might not do this. Which seems not be a very trivial task to come by. It would probably require a different parsing code for each package manager output.

This way we would leave all the mirror handling searching and stuff entirety to the distro itself. But maybe this is also a little to ambitious or out of scope for BoxBuddy. Even though I would love to have this feature 😆

[Dvlv]

I had a feature like this in Toobox-GUI but it felt a bit awkward. The only way I can see this being manageable is if most of the package managers have a way of specifying their output to be in some kind of easily-parseable format.

Otherwise the code would be very fragile - any updates to the output would break parsing, and we could end up with constant checks for which version of each distro a box has, and rolling distros we'd have no way of knowing if the box is in a version before or after any format change.

[Dvlv]

Planning on releasing tomorrow in 2.1.0

[Dvlv]

Released in 2.1.0