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.

On samedi, 5 mars 2016 19.30:22 h CET Jan Engelhardt wrote:

On Saturday 2016-03-05 17:40, Bruno Friedmann wrote:

...

...

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 [...] Once MapServer 8.0 appears in the future, move mapserver to 8.0 and create mapserver7 if needed.

Moreover having one versionned and not the other will complicate the handle of proper alternative /usr/lib/mapserv

You can always choose to a use versioned directory like /usr/lib/mapserv7 even if the package is called just "mapserv". The idea of using a package name of "mapserv" is to ensure automatic upgrade from 6->7. In fact, you can even pull this off like gcc does, e.g. gcc requires gcc4 in old openSUSE and gcc5 in newer ones.

This was the last step idea, having a kinda meta-package called mapserver which call the last available version this is also what postgresql do.

but on packaging side, have a mapserver package which install /usr/lib/mapserver7 then transform this one to a mapserver7 when 8 will look like to me a bit silly when we can have it directly.

Now I'm not trying to force anything, I can build it as I want and use it where I need it.

It's just a question of mutualizing effort.

I wouldn't care that much about the "first run" of trouble educating users to move their actually installed mapserver to mapserver6 and mapserver7 package as they want to. If we would have so much users of this package, they will have cry since almost one year when 6.4.2 was released for fixing security bugs. Guess what, nobody complains -> imply -> nobody was using it.

I've during that time my own build (with some extra flags) on a branch in my home.

To resume, I will continue to have to use mapserver, and as all server I'm setting up are based on openSUSE I will have to have it working. So yeap in a sense I 'm deeply voluntaring to maintain it. and get it available on Factory. I've tested and got a working way to have m6 and m7 available at the same time on openSUSE. I think we have a first good start, and a bit of help in making a meta-package would be great. We can argue for eternity, but we have some of this kind of package (like postgresqlXX, python and python3 equivalent) and I'm confident to the fact that if mapserver packaging is following the same spirit of others, then consistancy is increased and learning curve is shorter.

I'm open to any use case I can have missed, dude if I was God everybody would have noticed it :-)))

btw I will analyze deeply and carefully any sr to my App:geo branch ;-)

ps: force yourself to only respond to the mailing list, I don't need another one copy :-)