VTK and GDAL

schivmeister · 2015-09-24 15:03:22

Hey all

UPDATE: A rebuild has been done against an initial patch. If you already have gdal1, please uninstall and reinstall vtk [6.1.0-10 -> 6.1.0-11] so that gdal1 is removed from the system.

I should have posted this sooner but there is a bit of a mess with VTK and GDAL for which I am responsible. If you have vtk installed in your system along with any one of the following:

gpsdrive
mapnik
mysql-workbench
postgis
qlandkartegt
openscenegraph

Any attempt to update your system will be prevented by the conflict between gdal and a gdal1. [1] A gdal 2.x rebuild [2] was staged for a long while and vtk was preventing it from moving forward (it is not API-compatible with the new gdal, which is a core dependency) -- there were more rebuilds that were waiting in line.

The gdal1 package is only a tentative inconvenience as I did not want to drop vtk. Due to time constraints I could not attempt a patch in the several months that the rebuild was sitting idle and upstream was not ready to migrate. Another developer (anatolik) has stepped up to help and may take over maintenance of the package. Anyone is also welcome to contribute.

Please bear with us in the meantime, thanks!

[1] https://bugs.archlinux.org/task/46346
[2] https://www.archlinux.org/todo/gdal-200/

Last edited by schivmeister (2015-09-25 15:19:32)

optiligence · 2015-09-25 12:34:52

Am i right to assume that this should be fixed with the latest pkgrel of vtk (6.1.0-11)?
If so, then there is still something wrong.
I still have gdal1 1.11.2-1, so my system tries to update gdal1 to 1.11.2-2 as well as pull gdal 2.0.0-1 for vtk but fails with their conflict.
I have no other package besides vtk which requires gdal.
I guess it’s the ›provides gdal‹ of gdal1 1.11.2-1 which confuses pacman here.
Shouldn’t it do the conflict resolution with the updated package info (gdal1 1.11.2-2 without the provides).
Is this a pacman bug?

Last edited by optiligence (2015-09-25 12:38:51)

schivmeister · 2015-09-25 14:08:01

Sorry, yes, I was just going to post about this.

So I've attempted an initial patch and pushed a rebuild directly to [community]. A slight inconvenience again to get this working is to remove gdal1, and it is best to do this by simply removing vtk if you received the gdal1 update:

pacman -Rs vtk

And then resync'ing the database to get the new vtk:

pacman -Sy vtk

Let us know if anything still goes awry.

Btw, you are correct that there is a gdal1 release bump that fixes a technical mistake (the provision), and now there is a release bump to vtk that gets rid of the gdal1 dependency. However, gdal1 still exists in the system and therefore must first be removed to escape the loop, so to speak.

Last edited by schivmeister (2015-09-25 14:19:21)

optiligence · 2015-09-25 14:25:38

After doing a

pacman -Sy gdal1

to get the 1.11.2-2 update

then

pacman -Syu

correctly asks to replace it with ›gdal‹.

I’m asking if it should ask this in the first place – even with 1.11.2-1 still installed (but 1.11.2-2 in the update list) – and if a bugreport on pacman should be filed about it.

schivmeister · 2015-09-25 14:51:04

No, don't worry, it is not a bug. This is because I chose to not explicitly include a conflict with gdal1 -- pacman will therefore not have that knowledge and will not act against your system.

You either need to uninstall gdal1 or, like you did, update it prior to retrieving the updated vtk. It will be deleted, so there is no reason to keep it.

File a bug at our tracker if any functionality in vtk does not work as expected, in particular for reading in GDAL images; do not report upstream in this case.

Last edited by schivmeister (2015-09-25 14:54:13)

optiligence · 2015-10-01 14:32:33

Sorry to bother again.

schivmeister wrote:

pacman will therefore not have that knowledge and will not act against your system.

When doing a system update with gdal1 1.11.2-1 → 1.11.2-2 and vtk 6.1.0-10 → 6.1.0-11, pacman has the same knowledge it has when I do a partial update of gdal1 beforehand, yet it only presents the replace option in the latter case.

If this is indeed intended, it means that you can never fix a system with a broken provides info through an update but only through manual intervention.

Last edited by optiligence (2015-10-03 22:46:48)

schivmeister · 2015-10-03 20:01:39

optiligence wrote:

When doing a system update with gdal1 1.11.2-1 → 1.11.2-2 and vtk2 6.1.0-10 → 6.1.0-11, pacman has the same knowledge it has when I do a partial update of gdal1 beforehand

No, before the partial update, gdal1 provides gdal. After the partial update, it does not provide gdal. A full update will cause a conflict because the new vtk depends on gdal and the new gdal1 does not provide gdal. It is therefore considered a separate package by its own right, and pacman will not remove it without it being told explicitly that gdal1 is a conflict.

optiligence wrote:

If this is indeed intended, it means that you can never fix a system with a broken provides info through an update but only through manual intervention.

Sadly, yes -- this is not the package manager's fault, but the packager's fault.

optiligence · 2015-10-03 23:00:00

schivmeister wrote:

optiligence wrote:
When doing a system update with gdal1 1.11.2-1 → 1.11.2-2 and vtk 6.1.0-10 → 6.1.0-11, pacman has the same knowledge it has when I do a partial update of gdal1 beforehand
No, before the partial update, gdal1 provides gdal.

Conflict resolution exists to test if the system is valid only after a (full system) update, no?
It should also be conflictless in the first place, if conflict resolution was never bypassed.
The conflictlessness of a system with non-updated gdal1 1.11.2-1 and updated vtk 6.1.0-11 is of no relevance when in fact you want to update both.

schivmeister wrote:

After the partial update, it does not provide gdal.

This is also the case after the full system update…

schivmeister wrote:

A full update will cause a conflict because the new vtk depends on gdal and the new gdal1 does not provide gdal. It is therefore considered a separate package by its own right, and pacman will not remove it without it being told explicitly that gdal1 is a conflict.

Rather: new gdal1 does not provide gdal therefore vtk pulls in gdal.
gdal1 conflicts gdal and pacman can safely and should ask the »gdal and gdal1 are in conflict, do you want to remove gdal1«.

schivmeister wrote:

optiligence wrote:
If this is indeed intended, it means that you can never fix a system with a broken provides info through an update but only through manual intervention.
Sadly, yes -- this is not the package manager's fault, but the packager's fault.

But if the package gets fixed in a new iteration the package manager should use that updated info to resolve the issue.
Why should a corrected misconfiguration of a package always require user intervention after it got fixed.

Also gdal should conflict gdal1 for future updaters especially after gdal1 is removed from the repos. (although that doesn’t help the systems with gdal1 1.11.2-1)

nomorewindows · 2015-10-03 23:08:49

I don't know but it wouldn't let me update my system until the dependency hell was resolved.

schivmeister · 2015-10-04 08:49:29

schivmeister wrote:
A full update will cause a conflict because the new vtk depends on gdal and the new gdal1 does not provide gdal. It is therefore considered a separate package by its own right, and pacman will not remove it without it being told explicitly that gdal1 is a conflict.
Rather: new gdal1 does not provide gdal therefore vtk pulls in gdal.

That is exactly what I said (note that the older vtk required gdal1).

gdal1 conflicts gdal and pacman can safely and should ask the »gdal and gdal1 are in conflict, do you want to remove gdal1«.

Like I said very early on, I did not include a conflict, and therefore pacman cannot do this.

But if the package gets fixed in a new iteration the package manager should use that updated info to resolve the issue.
Why should a corrected misconfiguration of a package always require user intervention after it got fixed.

Yes, you are absolutely right here about troubling the user in order to fix a packaging mistake. I chose to trouble users instead of include a conflict with "gdal1" because it would be removed sooner rather than later. I simply chose to keep the gdal package as-is without introducing any conflict whatsoever, especially because I am not the maintainer.

Also gdal should conflict gdal1 for future updaters especially after gdal1 is removed from the repos. (although that doesn’t help the systems with gdal1 1.11.2-1)

If this were a critical package with a critical following, I would have posted the same cautionary on the front page, asking users to remove gdal1. This is not the first time we have required user intervention.

Anyway, I understand your concern and you are free to file a bug report against the vtk (yes, vtk, not gdal) package if you are disturbed by this. I just clarified with you that this is not a pacman bug.

Last edited by schivmeister (2015-10-04 08:53:51)

optiligence · 2015-10-04 14:17:32

schivmeister wrote:

I just clarified with you that this is not a pacman bug.

I’m still not convinced.

schivmeister wrote:

Like I said very early on, I did not include a conflict, and therefore pacman cannot do this.

You didn’t add a conflict with gdal1 to gdal, but gdal1 always had a conflict with gdal. (It even says: cannot update because gdal1 and gdal are in conflict)
Are you saying that the conflict must be specified in the other direction for pacman to offer you to replace it?
Because that does not explain why it works to partially update gdal1 beforehand. Only the provides is removed then, and i’m saying that, for conflict resolution, pacman should not care about the provides – or the package info in general – of packages which are subject to an update, because that tests for a fictive combination of packages. In fact it – correctly – doesn’t do so for dependency resolution, vtk wouldn’t pull in gdal if that weren’t the case.

If the conflict must be specified in the other direction for conflict resolution to work, then this is a bug if there is no legitimate reason for it. (The legitimate reason is what i’m looking for in this whole discussion)

Arch Linux

#1 2015-09-24 15:03:22

VTK and GDAL

#2 2015-09-25 12:34:52

Re: VTK and GDAL

#3 2015-09-25 14:08:01

Re: VTK and GDAL

#4 2015-09-25 14:25:38

Re: VTK and GDAL

#5 2015-09-25 14:51:04

Re: VTK and GDAL

#6 2015-10-01 14:32:33

Re: VTK and GDAL

#7 2015-10-03 20:01:39

Re: VTK and GDAL

#8 2015-10-03 23:00:00

Re: VTK and GDAL

#9 2015-10-03 23:08:49

Re: VTK and GDAL

#10 2015-10-04 08:49:29

Re: VTK and GDAL

#11 2015-10-04 14:17:32

Re: VTK and GDAL

Board footer