Opened 12 years ago
Closed 10 years ago
#37995 closed defect (fixed)
mapnik and py26-mapnik
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | stromnov (Andrey Stromnov) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | bpanulla (Brian Panulla), dbsgeo@…, cooljeanius (Eric Gallager), petrrr | |
Port: | mapnik py26-mapnik |
Description
What is the situation with mapnik and py26-mapnik? Why do both exist? mapnik appears to be current while py26-mapnik is vastly out of date and does not build and has several tickets filed against it and is no longer being maintained by its maintainer. Should py26-mapnik be replaced_by mapnik?
Change History (13)
comment:1 follow-up: 13 Changed 12 years ago by stromnov (Andrey Stromnov)
comment:2 Changed 12 years ago by bpanulla (Brian Panulla)
There were pretty serious changes to the Mapnik API for version 2. Would "replaced_by" cause an automatic upgrade from Mapnik 0.7 (as in py26-mapnik) to Mapnik 2.1?
comment:3 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Yes, that would be the purpose of adding that directive.
If there is a reason why an older mapnik should be kept, then it should be renamed from py26-mapnik to mapnik07 or something.
comment:6 Changed 10 years ago by petrrr
Could we get rid of the py26-mapnik
code by now? It is quite dated now, and mapnik is around for some while.
Not sure I understand the issue regarding replaced_by mapnik
, why this should create any problems due to the API changes. Mapnik seems to have no dependents. The only issue I could think of is that py26-mapnik
would correspond to mapnik +python26, while the default is +python27.
So what would be a smooth exit strategy?
comment:7 Changed 10 years ago by petrrr
See also tickets:
- #30187 (request for a py27-mapnik port) which probably should not be implemented;
- #32452 enhancement to py26-mapnik;
- #35323 defect py26-mapnik: undefined symbols boost::system::generic_category boost::system::system_category
- #36134 defect py26-mapnik @0.7.1_6+cairo+gdal+postgis+sqlite: build failure
comment:8 Changed 10 years ago by petrrr
Cc: | dbsgeo@… added |
---|
comment:10 Changed 10 years ago by dbsgeo@…
I am the previous maintainer but I no longer use Macports and so I would recommend removing py26-mapnik to prevent confusion.
comment:11 Changed 10 years ago by dbsgeo@…
I'll add: I am an active maintainer of the Mapnik project upstream, and any questions about Mapnik are appropriate at https://github.com/mapnik/mapnik/issues.
comment:12 Changed 10 years ago by petrrr
Okay, port py26-mapnik should be discontinues. However currently mapnik does not build due to #45944. This will be resolved with mapnik 3.0. So waiting until this is fixed to have a cleaner upgrade path.
comment:13 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to stromnov@…:
Yes, I think that py26-mapnik should be replaced by mapnik.
Done in r135506.
Yes, I think that py26-mapnik should be replaced by mapnik.
And mapnik is a C++ GIS library with optional python bindings (and other plugins), so mapnik must be in gis/mapnik, but not in python/py*-mapnik.