Open ramboman opened 1 month ago
ben-grande
commented
1 month ago This is not how a package manager works, it can't possibly resolve dependencies if it doesn't know from where to fetch. If you don't add the repos to dom0, it can't fetch, simple as that.
Please close as unnaplicable. Not a Qubes issue nor something that Qubes can fix in RPM. If the user wants, it is something that should be proposed to upstream RPM, but it really doesn't make sense.
marmarek
commented
1 month ago Technically, qubes-dom0-update could inspect dependencies (rpm -qpR) and then use updatevm to fetch them.
ben-grande
commented
1 month ago User has set the repo in the updatevm:
Copr repo for xfce4-i3 owned by fepitre 6.7 kB/s | 1.8 kB 00:00
Technically,
qubes-dom0-updatecould inspect dependencies (rpm -qpR) and then use updatevm to fetch them.
Dom0 qubes-dom0-update cleans the repo definitions on new fetches. User has added the repo definition ot the updatevm /etc/yum.repos.d (guessing). It doesn't interact with each other. Unless I'm mistaken, I don't know why this is better than adding the repo to dom0 if you are trusting the RPM anyway.
marmarek
commented
1 month ago User has set the repo in the updatevm:
But the package in question is fetched into dom0 already, no? I guess it's built in some (trusted) local qube.
I'm not sure what repo you propose to add in this case. Adding a local repo (baseurl=file://...) won't work, as qubes-dom0-update will try to use it in updatevm, so you end up with exactly the same issue.
qubes-dom0-update does use standard /etc/yum.repos.d dir, it doesn't clears it. It "just" copies it into updatevm and call dnf on it there.
ramboman
commented
1 month ago This is not how a package manager works, it can't possibly resolve dependencies if it doesn't know from where to fetch. If you don't add the repos to dom0, it can't fetch, simple as that.
Technically,
qubes-dom0-updatecould inspect dependencies (rpm -qpR) and then use updatevm to fetch them.
@marmarek is right. dnf can get the dependencies from the local package in a similar way as rpm -qpR, and then fetch them from the default Fedora repositories.
Dom0 qubes-dom0-update cleans the repo definitions on new fetches. User has added the repo definition ot the updatevm /etc/yum.repos.d (guessing). It doesn't interact with each other.
The xfce4-i3 repo is not required to resolve the dependencies. I just removed it from yum.repos.d in dom0. Doing what I did in my first message will give the same result whether the repo is there or not.
Copr repo for xfce4-i3 owned by fepitre 6.7 kB/s | 1.8 kB 00:00
Unless I'm mistaken, I don't know why this is better than adding the repo to dom0 if you are trusting the RPM anyway.
I was unable to install i3ipc-glib directly from the xfce4-i3 repo, because it contains two i3ipc-glib builds with the exact same version and build number. The package manager, somehow, always pick the one with a RSA/SHA1 signature which cause this error:
dom0 qubes.ReceiveUpdates+-sys-net[6449]: Error canonicalizing file: bad OpenPGP signature: InsecureAlgorithm(2)For more information, I made a post about it.
From there, I did not know when this problem will be solved. I did not know, if a future problem occurs, if it will be solved in a timely manner. I wanted to have more control over the situation. I decided to build the required packages myself locally. When I tried to install my own packages locally, it did not work, so I made another post about it.
ramboman
commented
1 month ago I just realized that this is not just about installing a local package. It is about installing a package from a path, whether it is a file path or an URL.
If the package manager, somehow, always choose the RSA/SHA1 version of i3ipc-glib, why not just download the RSA/SHA256 version directly using its URL.
If I try to install the i3ipc-glib package from the xfce4-i3 via its URL, I get this:
$ sudo qubes-dom0-update https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm
Using sys-vpn as UpdateVM to download updates for Dom0; this may take some time...
Fedora 37 - x86_64 2.1 MB/s | 82 MB 00:38
Fedora 37 - x86_64 - Updates 2.1 MB/s | 41 MB 00:19
Qubes Host Repository (updates) 476 kB/s | 2.5 MB 00:05
Last metadata expiration check: 0:00:05 ago on Wed Jul 24 14:13:25 2024.
i3ipc-glib-1.0.1-1.el7.x86_64.rpm 187 kB/s | 65 kB 00:00
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
i3ipc-glib x86_64 1.0.1-1.el7 @commandline 65 k
Installing dependencies:
glib2-devel x86_64 2.74.7-2.fc37 updates 570 k
json-glib-devel x86_64 1.6.6-3.fc37 fedora 224 k
libblkid-devel x86_64 2.38.1-1.fc37 fedora 17 k
libffi-devel x86_64 3.4.4-1.fc37 updates 28 k
libmount-devel x86_64 2.38.1-1.fc37 fedora 18 k
libselinux-devel x86_64 3.5-1.fc37 updates 151 k
libsepol-devel x86_64 3.5-1.fc37 updates 49 k
pcre2-devel x86_64 10.40-1.fc37.1 fedora 505 k
pcre2-utf32 x86_64 10.40-1.fc37.1 fedora 203 k
sysprof-capture-devel x86_64 3.46.0-1.fc37 fedora 58 k
Transaction Summary
================================================================================
Install 11 Packages
Total size: 1.8 M
Total download size: 1.8 M
Installed size: 9.1 M
DNF will only download packages for the transaction.
Downloading Packages:
(1/10): libblkid-devel-2.38.1-1.fc37.x86_64.rpm 75 kB/s | 17 kB 00:00
(2/10): libmount-devel-2.38.1-1.fc37.x86_64.rpm 78 kB/s | 18 kB 00:00
(3/10): json-glib-devel-1.6.6-3.fc37.x86_64.rpm 500 kB/s | 224 kB 00:00
(4/10): sysprof-capture-devel-3.46.0-1.fc37.x86 553 kB/s | 58 kB 00:00
(5/10): pcre2-utf32-10.40-1.fc37.1.x86_64.rpm 514 kB/s | 203 kB 00:00
(6/10): libffi-devel-3.4.4-1.fc37.x86_64.rpm 294 kB/s | 28 kB 00:00
(7/10): glib2-devel-2.74.7-2.fc37.x86_64.rpm 1.3 MB/s | 570 kB 00:00
(8/10): pcre2-devel-10.40-1.fc37.1.x86_64.rpm 658 kB/s | 505 kB 00:00
(9/10): libselinux-devel-3.5-1.fc37.x86_64.rpm 541 kB/s | 151 kB 00:00
(10/10): libsepol-devel-3.5-1.fc37.x86_64.rpm 518 kB/s | 49 kB 00:00
--------------------------------------------------------------------------------
Total 1.1 MB/s | 1.8 MB 00:01
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Qubes OS Repository for Dom0 2.9 MB/s | 3.0 kB 00:00
Qubes OS Repository for Dom0 1.2 MB/s | 11 kB 00:00
[MIRROR] i3ipc-glib-1.0.1-1.el7.x86_64.rpm: Curl error (6): Couldn't resolve host name for https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm [Could not resolve host: download.copr.fedorainfracloud.org]
[MIRROR] i3ipc-glib-1.0.1-1.el7.x86_64.rpm: Curl error (6): Couldn't resolve host name for https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm [Could not resolve host: download.copr.fedorainfracloud.org]
[MIRROR] i3ipc-glib-1.0.1-1.el7.x86_64.rpm: Curl error (6): Couldn't resolve host name for https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm [Could not resolve host: download.copr.fedorainfracloud.org]
[MIRROR] i3ipc-glib-1.0.1-1.el7.x86_64.rpm: Curl error (6): Couldn't resolve host name for https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm [Could not resolve host: download.copr.fedorainfracloud.org]
[FAILED] i3ipc-glib-1.0.1-1.el7.x86_64.rpm: Curl error (6): Couldn't resolve host name for https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm [Could not resolve host: download.copr.fedorainfracloud.org]
Curl error (6): Couldn't resolve host name for https://download.copr.fedorainfracloud.org/results/fepitre/xfce4-i3/epel-7-x86_64/05865327-i3ipc-glib/i3ipc-glib-1.0.1-1.el7.x86_64.rpm [Could not resolve host: download.copr.fedorainfracloud.org]To make the issue about installing packages from path+URL and not about installing local packages, should I (or):
?
marmarek
commented
1 month ago Lets step back and focus on the actual issue. The issue you face is that wrong version of i3ipc-glib is chosen and it's (rightfully) rejected by qubes-dom0-update. This needs fixing. @fepitre can you take a look?
Installing a package downloaded manually (likely skipping signature check) is not something we should recommend, and I don't think qubes-dom0-update should make it any easier.
How to file a helpful issue
The problem you're addressing (if any)
For now, to install a local rpm package in
dom0, I have to copy the rpm file in the UpdateVM so it is at the same file path as indom0.Example:
Let's suppose that the rpm file is
/tmp/i3ipc-glib.rpmIf the rpm file is only in
dom0:If the rpm file is only in the UpdateVM:
If the rpm file is in both:
The solution you'd like
qubes-dom0-update <rpm_file>should install the rpm file while also resolving correctly its dependencies, without the need to copy the rpm file to UpdateVM first.The value to a user, and who that user might be
Anybody who needs to install a package unavailable in any repository in
dom0, will be able to do so.Completion criteria checklist
(This section is for developer use only. Please do not modify it.)