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/root 581952 2004-08-19 12:27:15 ./usr/bin/legend -rwxr-xr-x root/root 581952 2004-08-19 12:27:15 ./usr/bin/scalebar -rwxr-xr-x root/root 581952 2004-08-19 12:27:15 ./usr/bin/shp2img -rwxr-xr-x root/root 581964 2004-08-19 12:27:15 ./usr/bin/shp2pdf -rwxr-xr-x root/root 581956 2004-08-19 12:27:15 ./usr/bin/shptree -rwxr-xr-x root/root 581952 2004-08-19 12:27:15 ./usr/bin/shptreetst -rwxr-xr-x root/root 581956 2004-08-19 12:27:15 ./usr/bin/shptreevis -rwxr-xr-x root/root 581956 2004-08-19 12:27:15 ./usr/bin/sortshp -rwxr-xr-x root/root 581956 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
