On Sat, 13 Nov 2010 19:20:23 +0000, Andy Spencer wrote:
> On 2010-11-13 10:58, David Paleino wrote:
> > IMHO, the name of your project is rather too generic ("libgis"). It should
> > be changed to something more descriptive, but that's your choice as
> > upstream at the end.
> >
> > Apart from this, you're very welcome to maintain it under the Debian GIS
> > Team umbrella. To join us, please join the pkg-grass [0] project on
> > alioth.debian.org.
> >
> > [0]: https://alioth.debian.org/projects/pkg-grass/
>
> I've never been good with names :) I agree that it is a little generic,
> but I would rather leave it the way it is. I can't find any conflicts in
> Contents-i386 and googling for "libgis" seems to indicate that it's a
> fairly unique name, apart from a subsection of GRASS.
>
> Maintaining it under the "Debian GIS Team" would be nice. That website
> looks pretty GRASS-specific though, would it be suitable for a non-GRASS
> related package?
Yes. The team is named "pkg-grass" mainly for historical reasons, now it
maintains all sorts of GIS-related software -- from GRASS to OpenStreetMap
things.
> > - In debian/control, you misinterpreted the meaning of Vcs-* fields. Those
> > should point to the location where the Debian packaging is kept, while you
> > pointed at the upstream repository. You can choose to maintain the debian/
> > dir there as well, or host it on Alioth within the Debian GIS Team (which
> > would be better for team-maintainance).
>
> Oops, I've removed the links for now and will add "proper" links once
> version control is set up for the debian files. Alioth seems like a good
> place, I'll look into how that works.
If you join pkg-grass, you could ssh into alioth and do:
$ cd /git/pkg-grass/
$ ./setup-repository libgis 'some description'
After that, you can use git.debian.org/git/pkg-grass/libgis.git as remote in
your packaging repository. Most (if not all) of the packages there use the
git-buildpackage layout -- you might want to read about "git-import-origin",
"git-import-dsc" and "git-buildpackage".
> [..]
> > - Your package doesn't seem to be lintian clean ;-) -- you pasted lintian's
> > output in debian/lintian.txt, and there it clearly says to a) close an ITP
> > bug and b) use a proper name for the binary (point 2 of my comments). Next
> > time please read it ;)
>
> The first lintian file I generated was actually much bigger ;)
> a) Fixed now (per Benoît's email) #603393 for reference
> b) I wanted to discuss this one a little further before trying to
> correct it. (See below)
Ack.
> Another point of interest is that mentors.debian.net says:
> intian warnings: none
> intian errors: none
> Even though there were some warnings. I copied the `lintian clean'
> message from the template it generated, but I'm not sure if it generated
> the `lintian clean' part or if that was hard coded.
Well, no. AFAICT, mentors.debian.net doesn't use sid's lintian -- while a
maintainer should always use that one.
> > - Library packaging in Debian has to follow certain policies. The binary
> > package you're producing should be named "libgis<SONAME>" (i.e. libgis0,
> > or similar). This ensures that any dependant package depends on the correct
> > version of the library.
> >
> > - Always in the lintian warning, it says you're missing a symbols file.
> > Since it's a C project, I strongly suggest you to make one (I personally
> > dislike C++ symbols files, but that's just me). Please read more at
> > http://wiki.debian.org/UsingSymbolsFiles
>
> (I wanted to address these comments together)
>
> Personally, I'm not too concerned with the symbols file, or library
> versioning at all for that matter. Now, I had better clarify before
> someone bashes me with the libtool manual ;)
Yeah. Such statements don't usually pass unpunished :-)
> As I mentioned in my initial email, libgis was developed to support
> another program called AWeather. Since AWeather is the only program that
> currently uses libgis and it depends on the latest version anyway, I
> don't expect there to be very many issues with library versioning.
>
> That being said, if/when I hear about other people wanting to use libgis
> in their own programs (which I hope they will) I will start caring much
> more about library versioning, a stable API, etc.
Uploading a library in Debian, you're giving other users the chance to use it,
and link against it. Even for private (as in not-published) projects. And
breaking users' software for no reason isn't good ;)
> Anyway, I suspect some library versioning will be required, but I think
> doing as little as possible would (for now) be the most efficient way to
> go. Does this sound correct for package names, or can I do without the
> 0.4?
>
> - libgis-0.4-0
> - libgis-0.4-dev
> - libgis-0.4-bin
> - libgis-0.4-doc
Nope.
What's required in the package name is the SONAME, which in your case is 0. So
the packages should look like:
- libgis0
- libgis-bin
- libgis-dev
- libgis-doc
Why the SONAME is only on the shared library package? Because it's the one
containing the library compiled packages will link against. In case you break
API, and so change SONAME (let's say, libgis1), libgis0 can stay installed and
thus co-exist.
Other "ancillary" packages (in this case: -bin, -dev, -doc) should usually come
unversioned. Especially -dev, so that it's easy to transition dependant
packages (for example, aweather if it was packaged) without sourceful uploads.
(search what "binNMU" means).
You might want to have a look at
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html .
Beware, it's (much) outdated, but I believe the essentials are still correct.
> (using -version-info 0:0:0 -release 0.4.1)
AFAIK -release is for the software version, which is different from the SONAME
thing. I hope you know how to handle changes in -version-info :)
FYI, you might also be interested in reading about abi-compliance-checker.
In any case, if there's something else to fix in the package, I'll warn you ;)
Kindly,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature