update to tinysparql leads to conflicting files and depency issues

BS86 commented

2024-09-19 18:06:36 +02:00

the package tinysparql replaces tracker3. But the replaces does not work when using ALHP, because:

replaces=('tracker3<=3.7.3-2')
conflicts=('tracker3<=3.7.3-2')

but the ALHP version is 3.7.3-2.1

this leads to a depency problem because gtk3 and gtk4 depend on tracker3 therefore removing tracker3 is not possible.

https://gitlab.archlinux.org/archlinux/packaging/packages/tinysparql/-/blob/main/PKGBUILD?ref_type=heads

the package `tinysparql` replaces `tracker3`. But the replaces does not work when using ALHP, because: ``` replaces=('tracker3<=3.7.3-2') conflicts=('tracker3<=3.7.3-2') ``` but the ALHP version is 3.7.3-2.1 this leads to a depency problem because gtk3 and gtk4 depend on tracker3 therefore removing tracker3 is not possible. https://gitlab.archlinux.org/archlinux/packaging/packages/tinysparql/-/blob/main/PKGBUILD?ref_type=heads

anonfunc commented

2024-09-19 18:10:26 +02:00

Owner

Is this solved by adding --assume-installed tinysparql and/or --assume-installed tracker3?

You can also try adding a specific version to --assume-installed.

Is this solved by adding `--assume-installed tinysparql` and/or `--assume-installed tracker3`? You can also try adding a specific version to `--assume-installed`.

anonfunc added the bug label 2024-09-19 18:10:41 +02:00

BS86 commented

2024-09-19 18:18:00 +02:00

Author

with running sudo pacman -Syu --assume-installed tinysparql the update applies but it breaks gtk during the update:

(14/19) Probing GTK3 input method modules...
/usr/bin/gtk-query-immodules-3.0: error while loading shared libraries: libtinysparql-3.0.so.0: cannot open shared object file: No such file or directory
error: command failed to execute correctly

afterwards, GTK applications are broken, I have repaired the system manually by running
sudo pacman -R tracker3 --assume-installed tracker3 and sudo pacman -S gtk3 which pulled in tinysparql as a dependency and re-ran the Probing GTK3 input method modules... step

Edit: running sudo pacman -R tracker3 --assume-installed tracker3 and after that applying the update should work without breaking the system but I can't test that scenario.

with running `sudo pacman -Syu --assume-installed tinysparql` the update applies but it breaks gtk during the update: ``` (14/19) Probing GTK3 input method modules... /usr/bin/gtk-query-immodules-3.0: error while loading shared libraries: libtinysparql-3.0.so.0: cannot open shared object file: No such file or directory error: command failed to execute correctly ``` afterwards, GTK applications are broken, I have repaired the system manually by running `sudo pacman -R tracker3 --assume-installed tracker3` and `sudo pacman -S gtk3` which pulled in `tinysparql` as a dependency and re-ran the _Probing GTK3 input method modules..._ step Edit: running `sudo pacman -R tracker3 --assume-installed tracker3` and after that applying the update **_should_** work without breaking the system but I can't test that scenario.

BS86 commented

2024-09-19 18:22:18 +02:00

Author

for the record, those are the files that conflict:

tinysparql: /usr/lib/girepository-1.0/Tracker-3.0.typelib exists in filesystem (owned by tracker3)
tinysparql: /usr/lib/libtracker-sparql-3.0.so exists in filesystem (owned by tracker3)
tinysparql: /usr/lib/libtracker-sparql-3.0.so.0 exists in filesystem (owned by tracker3)
tinysparql: /usr/lib/pkgconfig/tracker-sparql-3.0.pc exists in filesystem (owned by tracker3)
tinysparql: /usr/share/dbus-1/services/org.freedesktop.portal.Tracker.service exists in filesystem (owned by tracker3)
tinysparql: /usr/share/gir-1.0/Tracker-3.0.gir exists in filesystem (owned by tracker3)
tinysparql: /usr/share/vala/vapi/tracker-sparql-3.0.deps exists in filesystem (owned by tracker3)
tinysparql: /usr/share/vala/vapi/tracker-sparql-3.0.vapi exists in filesystem (owned by tracker3)

for the record, those are the files that conflict: ``` tinysparql: /usr/lib/girepository-1.0/Tracker-3.0.typelib exists in filesystem (owned by tracker3) tinysparql: /usr/lib/libtracker-sparql-3.0.so exists in filesystem (owned by tracker3) tinysparql: /usr/lib/libtracker-sparql-3.0.so.0 exists in filesystem (owned by tracker3) tinysparql: /usr/lib/pkgconfig/tracker-sparql-3.0.pc exists in filesystem (owned by tracker3) tinysparql: /usr/share/dbus-1/services/org.freedesktop.portal.Tracker.service exists in filesystem (owned by tracker3) tinysparql: /usr/share/gir-1.0/Tracker-3.0.gir exists in filesystem (owned by tracker3) tinysparql: /usr/share/vala/vapi/tracker-sparql-3.0.deps exists in filesystem (owned by tracker3) tinysparql: /usr/share/vala/vapi/tracker-sparql-3.0.vapi exists in filesystem (owned by tracker3) ```

anonfunc commented

2024-09-19 18:37:30 +02:00

Owner

Confirmed Working Solution

Would it be possible to first remove tracker3 with

pacman -R tracker3 --assume-installed tracker3

and then update normally with e.g.

pacman -Suy

That looks cleaner, ~~but I also have no way to test that atm~~.

Just got to test it. You do actually only need the first step, after that you can update as normal. The update then pulls in tinysparql automatically.

<h2>Confirmed Working Solution</h2> Would it be possible to first remove `tracker3` with ``` pacman -R tracker3 --assume-installed tracker3 ``` and then update normally with e.g. ``` pacman -Suy ``` That looks cleaner, ~~but I also have no way to test that atm~~. Just got to test it. You do actually only need the first step, after that you can update as normal. The update then pulls in `tinysparql` automatically.

BS86 commented

2024-09-19 18:39:34 +02:00

Author

and then update with
pacman -Syu --assume-installed tinysparql
That looks cleaner, but I also have no way to test that atm.

wouldn't that leave the system with an unresolved dependency?
tinysparql now provides tracker3, so it is the correct replacement, it just doesn't apply that way because the replaces check is too narrow.

> and then update with > ``` > pacman -Syu --assume-installed tinysparql > ``` > > That looks cleaner, but I also have no way to test that atm. wouldn't that leave the system with an unresolved dependency? tinysparql now provides tracker3, so it is the correct replacement, it just doesn't apply that way because the replaces check is too narrow.

anonfunc commented

2024-09-19 18:41:13 +02:00

Owner

To come back to the underlying problem, I'm not sure we can do much here that would not involve PKGBUILD editing.

If this stays an isolated case, then I think pinning this issue should suffice.

To come back to the underlying problem, I'm not sure we can do much here that would not involve PKGBUILD editing. If this stays an isolated case, then I think pinning this issue should suffice.

anonfunc commented

2024-09-19 18:43:48 +02:00

Owner

and then update with
pacman -Syu --assume-installed tinysparql
That looks cleaner, but I also have no way to test that atm.
wouldn't that leave the system with an unresolved dependency?
tinysparql now provides tracker3, so it is the correct replacement, it just doesn't apply that way because the replaces check is too narrow.

Between the steps yes, but not after. As soon as one installs tinysparql (which happens in step 2), tracker3 is provided by that package, as you say. ~~Only caveat would be that its marked as explicitly installed in this case, but that could be fixed by pacman -D --asdeps tinysparql I guess.~~ (does not happen with the solution above)

edit: just noticed that I mixed up the options on step 2, fixed now.

> > and then update with > > ``` > > pacman -Syu --assume-installed tinysparql > > ``` > > > > That looks cleaner, but I also have no way to test that atm. > > wouldn't that leave the system with an unresolved dependency? > tinysparql now provides tracker3, so it is the correct replacement, it just doesn't apply that way because the replaces check is too narrow. Between the steps yes, but not after. As soon as one installs `tinysparql` (which happens in step 2), tracker3 is provided by that package, as you say. ~~Only caveat would be that its marked as explicitly installed in this case, but that could be fixed by `pacman -D --asdeps tinysparql` I guess.~~ (does not happen with the solution above) *edit*: just noticed that I mixed up the options on step 2, fixed now.

BS86 commented

2024-09-19 18:44:06 +02:00

Author

I think that is ok. I don't expect that Arch developers will change their package for third party repositories

👍 1

anonfunc pinned this 2024-09-19 18:51:01 +02:00

WatermelonRei commented

2024-09-27 21:41:39 +02:00

GNOME just renamed the tracker3 to tinysparql, see https://blogs.gnome.org/carlosg/2024/07/14/goodbye-tracker-hello-tinysparql-and-localsearch/

I solved this problem via downloading the official old tracker3 package from Arch Linux Archive website: https://archive.archlinux.org/packages/t/tracker3/tracker3-3.7.3-2-x86_64.pkg.tar.zst

And downgrade the tracker3 3.7.3-2.1 to tracker3 3.7.3-2 by pacman -U tracker3-3.7.3-2-x86_64.pkg.tar.zst,
and then update as normal.

GNOME just renamed the tracker3 to tinysparql, see https://blogs.gnome.org/carlosg/2024/07/14/goodbye-tracker-hello-tinysparql-and-localsearch/ I solved this problem via downloading the official old tracker3 package from Arch Linux Archive website: https://archive.archlinux.org/packages/t/tracker3/tracker3-3.7.3-2-x86_64.pkg.tar.zst And downgrade the tracker3 3.7.3-2.1 to tracker3 3.7.3-2 by pacman -U tracker3-3.7.3-2-x86_64.pkg.tar.zst, and then update as normal.

anonfunc commented

2024-11-24 11:16:33 +01:00

Owner

this should be solved by now, closing

anonfunc closed this issue

2024-11-24 11:16:33 +01:00

anonfunc unpinned this 2024-11-24 11:16:37 +01:00

update to tinysparql leads to conflicting files and depency issues #258

Confirmed Working Solution