Untagged it.

Also untag -1 pls, getting another error now

ok. done.

not sure how to continue, can sombody help? Just from this morning it is still failing:

Running transaction
Transaction failed: Rpm transaction failed.
Warning: skipped OpenPGP checks for 457 packages from repositories: @commandline, testing-farm-tag-repository
  - file /usr/lib64/girepository-1.0/Tracker-3.0.typelib conflicts between attempted installs of libtinysparql-3.8~rc-3.fc42.x86_64 and libtracker-sparql-3.7.3-5.fc42.x86_64
  - file /usr/lib64/libtracker-sparql-3.0.so.0 conflicts between attempted installs of libtinysparql-3.8~rc-3.fc42.x86_64 and libtracker-sparql-3.7.3-5.fc42.x86_64
  - file /usr/share/dbus-1/services/org.freedesktop.portal.Tracker.service conflicts between attempted installs of tracker-3.7.3-5.fc42.x86_64 and tinysparql-3.8~rc-3.fc42.x86_64

---^---^---^---^---^---

I am not sure I get it... all of the tinysparql builds are now untagged.

So, how is it able to attempt installing? Is it pulling from a released compose and we need a new compose to fix it?

@nmontero did another tinysparql build and broke this again. Please stop building this until you're very sure you have solved the conflict. Multiple openQA tests are now failing on all updates with file conflicts, again: https://openqa.fedoraproject.org/tests/3180470#step/_setup_browser/11

So, @kevin , please untag tinysparql-3.8~rc-4.fc42 .

I've sent https://src.fedoraproject.org/rpms/tinysparql/pull-request/1 to fix one obvious remaining problem. However, there's another very obvious problem:

[adamw@toolbx tinysparql (bump-obsoletes)]$ sudo dnf repoquery --whatrequires "libtracker-sparql-3.0.so.0()(64bit)"
Updating and loading repositories:
Repositories loaded.
bijiben-0:40.1-12.fc42.x86_64
brasero-0:3.12.3-12.fc42.x86_64
gnome-applets-0:3.54.0-2.fc42.x86_64
gnome-photos-0:44.0-6.fc42.x86_64
gnome-usage-0:46.0-3.fc42.x86_64
grilo-plugins-0:0.3.16-8.fc42.x86_64
gtk3-0:3.24.43-3.fc42.x86_64
gtk4-0:4.17.3-1.fc42.x86_64
gtk4-devel-0:4.17.3-1.fc42.x86_64
nautilus-0:47.1-2.fc42.x86_64
netatalk-5:4.0.8-2.fc42.x86_64
polari-0:46.0-4.fc42.x86_64
rygel-tracker-0:0.44.1-2.fc42.x86_64

all of those packages will try to pull in libtracker-sparql because of this autogenerated library dependency. They won't be satisfied by libtinysparql because it does not provide libtracker-sparql-3.0.so.0()(64bit).

For this to work, you at least need to do a side tag update which contains rebuilds of everything that depends on libtracker-sparql-3.0.so.0()(64bit). I think gnome-music also needs an adjustment because it has an explicit dependency on libtracker-sparql3, which libtinysparql does not provide.

So, @kevin , please untag tinysparql-3.8~rc-4.fc42 .

Done.

Update: we have also had to untag tinysparql-3.8~rc-5.fc42 , as it was also broken. I've looked into it a bit, and this is what I've found.

the libtinysparql package actually has a libtracker-sparql-3.0.so.0 file in it, which is presumably meant to provide compatibility with existing packages that require that library. That file is just a symlink to libtinysparql-3.0.so.0 .

However, the existence of that symlink does not cause RPM's dependency generator to make the package provide libtracker-sparql-3.0.so.0()(64bit). So packages that require the library actually still try to pull in libtracker-sparql , and the conflicts happen.

I don't know if providing a 'compatibility symlink' for a library like this really works. If it does, fine, but we still need to deal with the dependency issue somehow. I played around with the dependency generator for a bit - it's /usr/lib/rpm/rpmdeps, you can just run /usr/lib/rpm/rpmdeps --provides <somefile> and see what it spits out. AFAICT, it never produces anything for symlinks, only for 'real' files. I didn't find any way to make it produce anything for a symlink. Even if it did, it seems like the provide it generates is based not on the filename but on the soname, viz:

[adamw@toolbx lib64]$ /usr/lib/rpm/rpmdeps --provides libtinysparql-3.0.so.0.800.0 
libtinysparql-3.0.so.0()(64bit)
[adamw@toolbx lib64]$ mv libtinysparql-3.0.so.0.800.0 foo.bar
[adamw@toolbx lib64]$ /usr/lib/rpm/rpmdeps --provides foo.bar
libtinysparql-3.0.so.0()(64bit)

so I don't think we're ever going to get the dependency generator to spit out what we need here. Potentially we could just write an appropriate provide into the spec, but that feels a bit icky and I don't even know what macro to use to get (64bit) (it's not %_isa, that gives you (x86-64)).

So, this is still broken, but not sure how to fix it. Either figure out how to force a provides in there, assuming the symlink will actually work for all the dependent software, or change it so tinysparql provides a "real" libtracker-sqlite library file with a correct soname, I guess. Or just go ahead and patch/rebuild all dependencies against libtinysparql, on a side tag, and give up on the compat interface.

I'd say it's perfectly fine to just hardcode the right Provides, including the (64bit) part. We would just need an appropriate %ifdef to use one version for 64-bit architectures and the other version for 32-bit architectures.

But the list of packages needing rebuilt is sufficiently small that it's probably also easy to simply rebuild everything.

they would presumably need patching to actually search for and link against libtinysparql instead of libtracker-sparql too?

No, as long as the new package Provides the old soversion dependency to satisfy RPM, we should be good. The symlink should be adequate to ensure everything works once installed.

I think we're going to go ahead and just rebuild everything rather than worry about the dependencies, though.

I meant, if we're going to rebuild them they would need patching to know to look for libtinysparql (if this isn't already done).

Hmmm, you might be right.

We found that tinysparql installs a compatibility pkg-config file, so rebuilds should probably be fine.

Yeah, I did a test build of gtk3 and it can build successfully against libtinysparql-devel via the compat pkgconfig file, and winds up with a dep on the new soname - libtinysparql-3.0.so.0()(64bit).

so, we have a couple options I guess:

• add a manual Provides in the expected format, let things get rebuilt naturally over time
• rebuild all deps in the side tag, skip the manual Provides

Current status: @nmontero is working through rebuilds on side tag f43-build-side-105037 , making sure that each one is actually building against tinysparql-devel.

update: everything ought to be built on the side tag now (@nmontero left netatalk and nautilus when she headed to bed, I've fixed and built those now, and also updated the handwritten dep in gnome-music and rebuilt that). i've run openQA tests on the side tag at https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=43&build=TAG_f43-build-side-105037-NOREPORT&groupid=2 , will see how that goes.

there's one failure on the tests but I think that's just because we're using a side tag so the builds aren't signed. probably fine to go ahead and create an update now.

Is this something that still requires attention or can the ticket be closed?

This should be closed.