FS#54139 - [mapnik] depends on nonexistent pycairo package

Attached to Project: Community Packages
Opened by Adam C (kabads) - Sunday, 21 May 2017, 10:43 GMT
Last edited by Sergej Pupykin (sergej) - Monday, 22 May 2017, 12:29 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jan de Groot (JGC)
Sergej Pupykin (sergej)
Jaroslav Lichtblau (Dragonlord)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
mapnik [community] now requires a different version of python-cairo [community] from the one in the repository that creates a conflict

Additional info:
* package version(s) - mapnik 3.0.13-2 requires pycairo which is a virtual package. pycairo points to python2-cairocffi 0.8.0-2
* config and/or log files etc.


Steps to reproduce:
# pacman -Syu breaks dependency on packages that requires pycairo.
# pacman -S mapnik


Error:

[adam@hark ~]$ sudo pacman -S mapnik
resolving dependencies...
warning: cannot resolve "pycairo", a dependency of "mapnik"
:: The following package cannot be upgraded due to unresolvable dependencies:
mapnik

:: Do you want to skip the above package for this upgrade? [y/N]
error: failed to prepare transaction (could not satisfy dependencies)
:: mapnik: requires pycairo


PKGBUILD for mapnik
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/mapnik
This task depends upon

Closed by  Sergej Pupykin (sergej)
Monday, 22 May 2017, 12:29 GMT
Reason for closing:  Fixed
Comment by PunkiD (PunkiD) - Sunday, 21 May 2017, 14:46 GMT
the pycairo package, in arch is python-cairo or python2-cairo
Comment by Jens G (Thah) - Sunday, 21 May 2017, 15:00 GMT
The recent update of python2-cairo to v1.13.1-1 removed the 'Provides: pycairo=${pycairoVERSION}' line. Might be a mistake,
might be cleaning out overcomplicated stuff.
Comment by Jeff Hodd (jghodd) - Sunday, 21 May 2017, 19:48 GMT
It's a mistake. python2-cairo and python-cairo install to /usr/lib/pythonX.X/site-packages/pycairo-X.X.X... So, it is, in effect, the pycairo package. Besides, I think it would easier to restore the 'provides' directive to the PKGBUILD than it would be to get all the maintainers of all the packages that depend on pycairo to change their builds in the near term - and it needs to be done asap because it's breaking system updates.
Comment by Jan de Groot (JGC) - Sunday, 21 May 2017, 21:32 GMT
There's only one package that still depends on the pycairo provides, so I see no reason to keep it around for much longer. The rename from pycairo to python2-cairo was done in 2010, we're over 6 years later now. It's time for packages to catch up with the correct package names.
Comment by Jeff Hodd (jghodd) - Sunday, 21 May 2017, 21:49 GMT
I don't think you're wrong, but the way this was done is a mistake. People's system updates are breaking which, at the very least, means having to deal with the inconvenience of figuring out which package caused the problem, what the problem is, telling pacman to ignore the update, and periodically checking back on the package causing the issue until it gets fixed. This change should have been coordinated with the maintainer of the mapnik package (and any other maintainer of packages that might depend on pycairo) and not just sprung on an unsuspecting user base. Right now, the mapnik maintainer has a new 3.0.13-3 version in staging which still contains the pycairo dependency. Please talk to one another to get this sorted.
Comment by Sergej Pupykin (sergej) - Monday, 22 May 2017, 12:28 GMT
updated mapnik in community and community-staging with python2-cairo dep

Loading...