On samedi, 5 mars 2016 14.40:26 h CET Angelos Tzotsos wrote:
Hi Bruno,
I would prefer to avoid having the same name issue once again as we did with postgis2, grass7 etc. This is why I propose to upgrade our existing mapserver package to latest upstream (7.0.1) and create a new mapserver6 package (as you propose) for the old version. Once MapServer 8.0 appears in the future, move mapserver to 8.0 and create mapserver7 if needed.
Thoughts?
Best, Angelos I would have agree, if a) upstream didn't ask for that, and we able to do it :-) b) map file compatibility would be better
Moreover having one versionned and not the other will complicate the handle of proper alternative /usr/lib/mapserv /usr/bin/* etc... Actually, on the proposed packages is correctly handled and make it clear. Upgrading the actual mapserver to 7.0.1 as it is will forbidden the use of alternatives in whatever future, delaying the push to Factory. no ? So we got two choices: not having an older mapserver package, which will annoy (as actually) people who need to revisit and fix their map files once the new version hit their system. And all of us who are maintaining map files know how this can be a long boring job. Or we got the ability to have both of them working. the other way around would be to have 2 version of mapserver mapserver -> always current mapserver6 -> previous upstream still maintained But then come the nightmare of naming correctly the mapscript module, the spec etc And both should have to conflicts has the binaries will have the same name. My pov is make them alternatives ready, as we have it for example python packages and or postgresqlXX version. I was not able to check what will happen if I've already mapserver 6.4.1 installed, then the package is deleted and new mapserver6 appear ...
On 02/29/2016 11:09 PM, Bruno Friedmann wrote:
Hi dear rpm'ers!
Since always, having an upgrade in Mapserver ( mapserver.org ) can be a real pain when the syntax of the mapfile change creating breakage in serving your map.
Making the changes take always a maximum of time. And sometimes you could have an old project that will be retired in two months, when you want to start a new one on the newer version right now ;-)
Wouldn't be a dream to have both the newer and old (still bugfix and security release) available at the same time ? Read below, this become near a reality.
Last week, during TOSprint in Paris organized by osgeo, I've been enough lucky to spend my time with upstream mapserver. And the request of being able to have all the supported version would be a nice to have from upstream point of view. I've took the challenge ;-)
Here's the news.
Starting with the bad ones, mapscript part is lacking maintainers, and/or fundings. It should be considered already deprecated, and in a near future if there's no changes it could be move to /dev/null. If you use it, especially in a professional context I would like to invite you to take contact with mapserver. Due to this lack of maintenance, mapscript modules (java,perl,php,python) are not able to have a versionned lib. As such there's no way to have 2 mapscript installed from differents versions.
The good news, actually I've been able to build mapserver6 (6.4.3) and mapserver7 (7.0.1) packages which works smoothly here.
https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Applic...
https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Applic...
Before sending them to Application:Geo I would propose a period of review to the above project. Getting your feedback there: use this mailing list or obs comment/bug link is important.
I'm not 100% satisfied by the java mascript naming libjavamapscript I would prefer to move it to java-mapscript like the others module, but rpmlint on certain plateform like 13.2 just tag it with 10000 badness :-( If you have a better idea for implementation, don't hesitate to speaking, or best, branch and sr ;-)
Thanks for your attention.
-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org