> On Mon, Sep 15, 2014 at 11:14:02AM +0300, Angelos Tzotsos wrote:
>> +1. I already plan to upload all the packages I did initially to UbuntuGIS.
> So it is *really* short time to do this if you want to reach the next
> stable Debian release. Please let us know if you need any help to
> realise your plan.
Thanks a lot for wanting to contribute to debian GIS.
As discussed on IRC I was going to have a look at pycsw first, and
then decide which packages we would tackle later (zoo and owslib).
Some comments already:
1) upstream tarball: your upstream tarball contains a lot of things
which should not have been there, including a file pycsw-1.8.2.tar
and some temporary files. Since you are using github, I would
recommend using the tarballs created by github, which are clean .
For packaging it is important to choose where we should watch for new
versions: on github or on download.osgeo.org?
2)The debian gis policy: contains some really useful information
for packaging. Print it and hang it above your bed if you are
old-fashioned, or anyway read it carefully.
One of the most obvious things you should definitely use is lintian.
It is documented in the policy mentioned before. It will complain
about many things which are not yet perfect in your package
You can run it on the source package and on the binary packages. One
of the things it will note is that you should not be installing to
/var/www/html, I would use /usr/share/pycsw .
3)To do this move, you should add an apache site and enable it. The
correct way is discussed in . Definitely you should not add you
config file under mods-enabled but under mods-available and then
enable them (this allows one to disable them easily).
There are some more lintian issues, which you should definitely check
analytics. They should point to local libraries (ideally packaged or
with source) and analytics should be removed.
5) I notice you build one file in your postinst script (index.html°. I
think this is probably something you want to do while building the
package, not in the postinst script. If you do it there you should
delete the file anyway when uninstalling.
It may be a long list, but I think once you manage to put the files
under /usr/share/pycsw and /etc/pycsw for the configuration and make
it work this the others are relatively easy to tackle. I suppose this
will need a patch to the upstream code to look in the right place for
Anyway, as you noticed I filed an ITP bug  for pycsw and imported
the sources to our git repository. Perhaps we should first bump to
the last version of pycsw before changing the packaging? If anything
is unclear, ask on this list - many people are more knowledgeable then