Indeed. It looks like the guide needs to be reverted to one that explains installation using rpm.
[user@disp4093 ~]$ sudo dnf install ./local-5.10.1-linux.rpm
Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
Last metadata expiration check: 0:00:09 ago on Sat Mar 20 17:50:43 2021.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
local x86_64 5.10.1-20210305.4 @commandline 142 M
Installing dependencies:
ncurses-compat-libs x86_64 6.2-3.20200222.fc33 fedora 326 k
nss-tools x86_64 3.62.0-1.fc33 updates 531 k
Transaction Summary
================================================================================
Install 3 Packages
Total size: 143 M
Total download size: 857 k
Installed size: 816 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): nss-tools-3.62.0-1.fc33.x86_64.rpm 230 kB/s | 531 kB 00:02
(2/2): ncurses-compat-libs-6.2-3.20200222.fc33. 140 kB/s | 326 kB 00:02
--------------------------------------------------------------------------------
Total 203 kB/s | 857 kB 00:04
Package local-5.10.1-linux.rpm is not signed
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
[user@disp4093 ~]$
Thanks for testing. I’ve now reverted the instructions on the fedora part and added the parameter to allow installing unsigned packages. Additionally I’ve also added disclaimer explaining the reasoning behind the security workaround and a pointer to the Qubes Security Bulletin.
The debian ones are still the same (easy ones) you suggested.
You shouldn’t need to uninstall the package (or remove the .deb file from wherever you downlodaded it) @adamrichards.
When installing the more recent version, you should see confirmation in the output of the apt command that the packaged was updated from the previous to the new version. They are different versions of the same package after all, and apt is able to detect that.
This is more or less what I’ve ended up doing. Good to know I’ve found a good way. The way I think about it, once I’m in the standalone I just treat it like it’s a normal Linux system.
This was very concise. I wish I’d found this when I first started using Qubes. Guess I should have looked through the forum more, lol.
It took me a few days of pain to figure out how to install some of the proprietary and non-repo stuff I need to run.
It is also possible to do it on TemplateVMs but that is a bit more involved – let’s leave that as homework.
You mention that there is a different method for doing a deb install on template VMs, but you never followed up with the “homework” and explained how to do this in templates. The problem with standalone VM’s is you can’t update them securely I dont think.
Can you please explain how to do this in template VM’s?
The same exact thing can be done in Template VMs. The only difference really is that you install in the template but don’t run it there.
The reason why I suggested installing it in a standalone is because often times these debs are not verified and may contain untrusted components (not to mention outdated software). The it’s prone to becoming outdated ( you have to install the new deb to keep it up to date), which is bad security-wise. And if it’s something that runs at the system startup, you may end up exposing all your VMs based on the template.
So I generally would do this in a standalone but in the template it’s also fine as long as you understand the risks.