Comments
carlwgeorge
provided feedback
on vim-nerdtree-7.1.3-2.el10_1
6 months ago
Can you please provide a link to guidelines or similar where it says that it is recommended to use a with statement in that case?
I don't think we have it written in any guidelines, but it's explained in a bit more depth in the original bug and the corresponding issue that lead to the creation of the with operator. Basically, with enforces that all the operands are fulfilled by the same package. When you use multiple requires (or the and operator) the separate operands can be satisfied by different packages, which can really go off the rails when versioned compat packages are involved. The way you have it works now with just libev-devel present, it could break in the future if a libev5-devel package is introduced that also provides libev-devel(x86-64). In that case your >= requires would be satisfied by libev5-devel, and your < requires would be satisfied by libev-devel, and the build would fail because the packages conflict with each other and couldn't be installed at the same time.
I have to assume that this very strict dependency is sensible and necessary.
These type of dependencies between subpackages of the same build are usually just boilerplate. You can see this yourself if you run rpmdev-newspec libfoo. The version requirement is usually quite important to ensure software functionality, but the release requirement is mainly intended to forcibly keep the subpackages from the same build in sync. Since in this case the subpackages are not coming from the same build, it's impossible to keep them perfectly in sync, so in my opinion the release requirement does more harm than good.
I honestly do not know which is the best. Number 2 seems to be the option that best mimics the original package without getting into too many issues.
Method 2 that you went with is fine for now, but if/when libev gets a release bump your subpackages will no longer install. At that point I would advise you to consider switching to method 3.
The recommended way to do a ranged dependency is the with operator.
https://rpm.org/docs/4.20.x/manual/boolean_dependencies.html
It is also preferable to use the built in expression expansion syntax instead of shelling out to the expr command.
https://rpm.org/docs/4.20.x/manual/macros.html#expression-expansion
That would give you a requires like so:
Requires: (%{rhel_name}-devel%{?_isa} >= %{version}-%{rhel_release} with %{rhel_name}-devel%{?_isa} < %{version}-%[ %{rhel_release} + 1 ])
All that said, is it really necessary to match the libev-devel from CRB exactly? That puts you in a situation where a simple release bump of libev-devel for something innocuous causes libev-libevent-devel to no longer install. What I tend to do for my *-epel packages is set the requires to just be a matching version and ignore the release.
Requires: %{rhel_name}-devel%{?_isa} = %{version}
osbuild 156 is now available from appstream, allowing image-builder to install successfully.
libev-libevent-devel from this update doesn't install.
Error:
Problem: conflicting requests
- nothing provides libev-devel(x86-64) = 4.33-14.el10_1 needed by libev-libevent-devel-4.33-14.el10_1.x86_64 from @commandline
I think the requires on that package could be adjusted like so to get this working.
-Requires: %{rhel_name}-devel%{?_isa} = %{version}-%{release}
+Requires: %{rhel_name}-devel%{?_isa} >= %{version}-%{rhel_release}
Error:
Problem: conflicting requests
- nothing provides osbuild >= 156 needed by image-builder-26-1.el10_1.x86_64 from brew-135072043
- nothing provides osbuild-depsolve-dnf >= 156 needed by image-builder-26-1.el10_1.x86_64 from brew-135072043
- nothing provides osbuild-luks2 >= 156 needed by image-builder-26-1.el10_1.x86_64 from brew-135072043
- nothing provides osbuild-lvm2 >= 156 needed by image-builder-26-1.el10_1.x86_64 from brew-135072043
- nothing provides osbuild-ostree >= 156 needed by image-builder-26-1.el10_1.x86_64 from brew-135072043
The automated test is only failing because of the downgrade check, i.e. the previous build is not installable. This new build is installable.
The only part of the installability test that fails is the downgrade check, because the previous version of this package is not installable. This one installs fine.
Same for keepassxc.
This update changes the library soname within netplan-libs and needs to go through the EPEL incompatible update process.
root@rhel9:~# dnf -q repoquery --provides netplan-libs | grep so
libnetplan.so.0.0()(64bit)
root@rhel9:~# dnf -q --repo epel-testing repoquery --provides netplan-libs | grep so
libnetplan.so.1()(64bit)
This build was untagged due to being uninstallable, see #2321352 for more details.
This build has been untagged, see #2373967 for more details.
Some of these are not installable due to the release of this build not matching the RHEL one.
Error:
Problem 1: conflicting requests
- nothing provides perl-XS-Parse-Keyword(x86-64) = 0.39-7.el10_0 needed by perl-XS-Parse-Keyword-Builder-0.39-7.el10_0.x86_64 from epel-testing
Problem 2: conflicting requests
- nothing provides perl-XS-Parse-Keyword(x86-64) = 0.39-7.el10_0 needed by perl-XS-Parse-Keyword-tests-0.39-7.el10_0.x86_64 from epel-testing
Error:
Problem 1: conflicting requests
- nothing provides python3dist(netifaces) needed by netplan-1.1.2-1.el10_0.x86_64 from epel-testing
Problem 2: conflicting requests
- nothing provides systemd-networkd needed by netplan-default-backend-networkd-1.1.2-1.el10_0.noarch from epel-testing
This is uninstallable due to the release of this build not matching the RHEL one.
Error:
Problem: conflicting requests
- nothing provides iniparser = 4.1-18.el10_0 needed by iniparser-devel-4.1-18.el10_0.x86_64 from epel-testing
The best way to resolve this would be to drop the release from the dependency, only requiring a matching version.
-Requires: %{rhel_name} = %{version}-%{release}
+Requires: %{rhel_name} = %{version}
Error:
Problem 1: conflicting requests
- nothing provides perl(Mail::Box::Maildir) needed by notmuch-mutt-0.39-6.el10_0.noarch from epel-testing
Problem 2: conflicting requests
- nothing provides rubygem-mail needed by notmuch-vim-0.39-6.el10_0.x86_64 from epel-testing
Error:
Problem 1: conflicting requests
- nothing provides perl(Mail::Box::Maildir) needed by notmuch-mutt-0.39-6.el10_1.noarch from epel-testing
Problem 2: conflicting requests
- nothing provides rubygem-mail needed by notmuch-vim-0.39-6.el10_1.x86_64 from epel-testing
Error:
Problem: conflicting requests
- nothing provides systemd-networkd needed by netplan-default-backend-networkd-1.1.2-1.el10_1.noarch from epel-testing
Error:
Problem: conflicting requests
- nothing provides python3dist(netifaces) needed by netplan-1.1.2-1.el10_1.x86_64 from epel-testing