Bug#138971: ITP Mapserver
Hello! [Wed, 18 Aug 2004] Paul Baker wrote: I also have been maintaining a debian package for mapserver. I have not kept as up-to-date with the upstream releases as Scott has (I'm at 4.0.1) but hey isn't that the Debian way? I'm building 4.2.2 packages right now. Your diff is small enough to be flexible. Add to your /etc/apt/sources.list if you want: deb http://www.paulbaker.net/debian stable main deb-src http://www.paulbaker.net/debian stable main I should mention that I have built my package against Woody (by also backporting all of the dependencies, and whoa was that a lot of work). I know. But testing or unstable have all dependencies already uploaded. My package is also mentioned on the MapServer wiki: http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?DebianLinux I have broken mine out into three separate packages: mapserver-cgi, mapserver-utils, and libmapscript-perl. I have not attempted to build any of the other Mapscript language bindings. Good. They can be added on a case-by-case basis. My hope was to one day upload the package into Debian, but don't feel it is quite yet ready. The main things I see as show stoppers are: 1. No manpages for any of the utils. Policy requires each to have a manpage. No upstream plan to provide these. This is not as bad as it sounds. There are more than 1000 packages with missing manpages: http://lintian.debian.org/reports/Tbinary-without-manpage.html OTOH: Writing reasonable manpages is a small task. 2. Definitely would want to build a mapscript-php4 package. I have not spent much time trying to make this happen. It seems to me that there were once problems with the system-regex'es that were compiled into Debian's PHP. But maybe that is not the problem anymore. 3. Probably would also want to build a mapscript-python package. java, php, python, ruby and tcl bindings are not built at them moment. If you build the ones that can be easily done now, you can fix and add the others later. 4. Finally, we may want to provide multiple flavours as of the package. Mapserver can be compiled with A LOT of features, or very few features. But everything is pretty much either turned on or off at compile time. So do you build the package with everything compiled in? Or do you scale it back? Or do you provide multiple versions? No. Somewhere it says that you should enable as many options as reasonably possible but split them into several packages if possible and feasible. These are all things I wanted to sort out before wasting Debian's time with the package. But if there is a sponsor (you Robert) that is willing to help work through these issues, I have no problem wasting your time. :-) I'll try to sponsor the package as much as I can. That might be quite irregular but OTOH I'll have times of high activity. What bothers me most at the moment is the following: -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/legend -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/scalebar -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/shp2img -rwxr-xr-x root/root581964 2004-08-19 12:27:15 ./usr/bin/shp2pdf -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/shptree -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/shptreetst -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/shptreevis -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/sortshp -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/tile4ms libmap.a gets statically compiled into all binaries. You should link the binaries against the shared library and create a separate package. The rest looks quite clean and well done. Robert. -- Foolproof Operation: No provision for adjustment. signature.asc Description: Digital signature
Bug#138971: ITP Mapserver
Hello! [Thu, 19 Aug 2004] Paul Baker wrote: Upstream has never meant for libmap.a to be a shared libary from what I gather. The build process does not support it in the slightest. (unless this changed in 4.2.x) I don't have enough experience with C to be or in 4.2.2 it does: make libmap.so But that would have to be tweaked to contain a SONAME, be -fPIC (or not..). it's many different possible build processes to be able to turn that into a shared library, so for now it would have to continue to be static. Hmm. To me missing manpages cause far less pain than the fact that libmap.so is not a decent shared library. If I get time I'll dive into it to break it apart. Robert. -- Pryor's Observation: How long you live has nothing to do with how long you are going to be dead. signature.asc Description: Digital signature
Bug#138971: ITP Mapserver
On Aug 19, 2004, at 5:45 AM, Robert Jordens wrote: I'll try to sponsor the package as much as I can. That might be quite irregular but OTOH I'll have times of high activity. What bothers me most at the moment is the following: -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/legend -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/scalebar -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/shp2img -rwxr-xr-x root/root581964 2004-08-19 12:27:15 ./usr/bin/shp2pdf -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/shptree -rwxr-xr-x root/root581952 2004-08-19 12:27:15 ./usr/bin/shptreetst -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/shptreevis -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/sortshp -rwxr-xr-x root/root581956 2004-08-19 12:27:15 ./usr/bin/tile4ms libmap.a gets statically compiled into all binaries. You should link the binaries against the shared library and create a separate package. The rest looks quite clean and well done. Upstream has never meant for libmap.a to be a shared libary from what I gather. The build process does not support it in the slightest. (unless this changed in 4.2.x) I don't have enough experience with C to be or it's many different possible build processes to be able to turn that into a shared library, so for now it would have to continue to be static. -- Paul Baker Yes, we did produce a near-perfect republic. But will they keep it? Or will they, in the enjoyment of plenty, lose the memory of freedom?” -- Thomas Jefferson in a letter to John Adams GPG Key: http://homepage.mac.com/pauljbaker/public.asc
Bug#138971: ITP Mapserver
Hi! You participated in the discussion about packaging the UMN masperver for Debian. Who of you is still interested in working of the package? What are the problems? I'd like to sponsor uploads. Robert. -- Bowie's Theorem: If an experiment works, you must be using the wrong equipment. signature.asc Description: Digital signature
Bug#138971: ITP Mapserver
I can't speak for mapserver as it exists today, I've since been focussing on more promising options for my needs, but as it was the last time I looked at it, the problem is not finding an uploader, rather with finding someone who'll take the time with upstream to turn a rather successful hack into something resembling a policy compliant library, set of language bindings, and utilities. I'm not likely to spend much time on this particular package in the near future unless someone was interested in funding that work (and even then...), but if someone is interested in picking it up, I'll answer any questions that I reasonably can. best, Ron On Wed, Aug 18, 2004 at 01:29:48PM +0200, Robert Jordens wrote: Hi! You participated in the discussion about packaging the UMN masperver for Debian. Who of you is still interested in working of the package? What are the problems? I'd like to sponsor uploads. Robert. -- Bowie's Theorem: If an experiment works, you must be using the wrong equipment.
Bug#138971: ITP Mapserver
On Wed, 18 Aug 2004, Robert Jordens wrote: You participated in the discussion about packaging the UMN masperver for Debian. Who of you is still interested in working of the package? What are the problems? I have packages, and am still using MapServer (so can test new ones). The status is still as posted previously. Packages at http://cscott.net/Debian/MapServer/ PHP/MapScript is still not included, although I might be a little bit more motivated to try. --scott Castro COBRA JUDY $400 million in gold bullion shotgun RNC hack assassinate Register to vote! http://www.yourvotematters.org/VerifiedVoting ( http://cscott.net/ )
Bug#138971: ITP Mapserver
Hello! [Wed, 18 Aug 2004] C. Scott Ananian wrote: I have packages, and am still using MapServer (so can test new ones). The status is still as posted previously. Packages at http://cscott.net/Debian/MapServer/ PHP/MapScript is still not included, although I might be a little bit more motivated to try. --scott You would have to split the package in functional parts (libraries, cgis utils, server). Robert. -- Random, n.: As in number, predictable. As in memory access, unpredictable. signature.asc Description: Digital signature
Bug#138971: ITP Mapserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 18, 2004, at 8:30 AM, C. Scott Ananian wrote: On Wed, 18 Aug 2004, Robert Jordens wrote: You participated in the discussion about packaging the UMN masperver for Debian. Who of you is still interested in working of the package? What are the problems? I have packages, and am still using MapServer (so can test new ones). The status is still as posted previously. Packages at http://cscott.net/Debian/MapServer/ PHP/MapScript is still not included, although I might be a little bit more motivated to try. --scott I also have been maintaining a debian package for mapserver. I have not kept as up-to-date with the upstream releases as Scott has (I'm at 4.0.1) but hey isn't that the Debian way? Add to your /etc/apt/sources.list if you want: deb http://www.paulbaker.net/debian stable main deb-src http://www.paulbaker.net/debian stable main I should mention that I have built my package against Woody (by also backporting all of the dependencies, and whoa was that a lot of work). My package is also mentioned on the MapServer wiki: http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?DebianLinux I have broken mine out into three separate packages: mapserver-cgi, mapserver-utils, and libmapscript-perl. I have not attempted to build any of the other Mapscript language bindings. My hope was to one day upload the package into Debian, but don't feel it is quite yet ready. The main things I see as show stoppers are: 1. No manpages for any of the utils. Policy requires each to have a manpage. No upstream plan to provide these. 2. Definitely would want to build a mapscript-php4 package. I have not spent much time trying to make this happen. 3. Probably would also want to build a mapscript-python package. 4. Finally, we may want to provide multiple flavours as of the package. Mapserver can be compiled with A LOT of features, or very few features. But everything is pretty much either turned on or off at compile time. So do you build the package with everything compiled in? Or do you scale it back? Or do you provide multiple versions? These are all things I wanted to sort out before wasting Debian's time with the package. But if there is a sponsor (you Robert) that is willing to help work through these issues, I have no problem wasting your time. :-) - -- Paul Baker All whitespace is equivalent except in certain situations. -- Footnote 82, ANSI C GPG Key: http://homepage.mac.com/pauljbaker/public.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBI/V3oxmRVfL3nlsRAs4pAJ9ullLjtM2AUhuArV3vU6rH4ng5tgCeJ7T9 t3VagE8LBMeyjUJWcv0lHII= =/fCb -END PGP SIGNATURE-
Bug#138971: ITP mapserver.
I'd like to see mapserver packaged as well: any progress on this bug? I'll volunteer to crank out some .debs, too, if everyone else has moved on. --scott Yeltsin SDI Nader Richard Tomlinson PLO Peking domestic disruption shotgun Albanian UKUSA DC RUCKUS security Hussein Waco, Texas Echelon ( http://cscott.net/ )
