what does E: no-library-dependency-on mean

[kalebskeithley]

or more specifically, liborc-devel.x86_64: E: no-library-dependency-on liborc1 /usr/lib64/liborc.so.1

I can't make any sense of it, and none of the things I've tried make any difference.

$ rpm -qp --requires liborc-devel-1.6.6-1.fc36.x86_64.rpm cmake-filesystem(x86-64) liborc.so.1()(64bit) liborc1(x86-64) = 1.6.6-1.fc36 ...

$ rpm -qp --provides liborc1-1.6.6-1.fc36.x86_64.rpm liborc(x86-64) = 1.6.6-1.fc36 liborc.so.1()(64bit) liborc1 = 1.6.6-1.fc36 liborc1(x86-64) = 1.6.6-1.fc36

$ rpmlint liborc1-1.6.6-1.fc36.x86_64.rpm liborc-devel-1.6.6-1.fc36.x86_64.rpm liborc-1.6.6-1.fc36.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.2.0 configuration: /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/licenses.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 3

liborc-devel.x86_64: E: no-library-dependency-on liborc1 /usr/lib64/liborc.so.1 3 packages and 0 specfiles checked; 1 errors, 0 warnings, 1 badness; has taken 1.5 s

[Conan-Kudo]

I think we're probably not handling (x86-64) properly in the dependency string. What do you think, @marxin?

[kalebskeithley]

that was the hint I needed. I changed the Requires: liborc1%{?_isa} in liborc-devel (removed the %{?_isa} and now rpmlint is clean. Thanks

[Conan-Kudo]

@kalebskeithley The thing is, it's wrong to not have the %{?_isa} suffix, so it's a bug on rpmlint's side.

[marxin]

@kalebskeithley The thing is, it's wrong to not have the %{?_isa} suffix, so it's a bug on rpmlint's side.

Do you mean the x86-64 in liborc1(x86-64) = 1.6.6-1.fc36? Do you really think it should be mandatory?

[brjsp]

@Conan-Kudo @marxin Allowing unarched dependencies here is definitely wrong! Consider the following scenario on x86-64:

1. User has libfoo1-i586 installed as a dependency of some software, providing /usr/lib/libfoo.so.1, but does NOT have libfoo1-x86_64 installed.
2. User installs foo-devel which contains a symlink /usr/lib64/libfoo.so -> libfoo.so.1
3. The resolver sees that libfoo1 is already installed, leaving a broken symlink and a setup unusable for actually building software depending on foo.

[Conan-Kudo]

@kalebskeithley The thing is, it's wrong to not have the %{?_isa} suffix, so it's a bug on rpmlint's side.

Do you mean the x86-64 in liborc1(x86-64) = 1.6.6-1.fc36? Do you really think it should be mandatory?

Yes.

[marxin]

Can you please attach here all the mentioned RPM files (use .tgz extension) and I will take a look.

[brjsp]

I'm not the OP, but you can see a minimal example here.

[Note that i did only %version instead of %version-%release because SUSE's reproducible builds infrastructure seems to have a problem with adding %release]