Re: libgss1 -> libgss2 transition?

[Russ Allbery]

Simon Josefsson <address@hidden> writes:

> Hi Russ, could you please upload now, to experimental first?  Use the
> latest daily snapshot [1] as the source, and the debian packaging stuff
> from CVS.  For me it builds under linux, mac, windows, and the debian
> package is lintian free on my system, so I think v1.0.0 is almost ready,
> but I'd like to avoid a 1.0.1 soon after just because it doesn't build
> on the buildd's.

Uploaded (to unstable) as 1.0.0.  Sorry, I didn't get to this yesterday.

A few minor things:

* I updated the watch file since it was still pointing to alpha.gnu.org,
  which actually doesn't have 1.0.0.

* Switched to debhelper compat level V7, since there's no reason not to.

* You'd been adding the multi-author changelog author notation even for
  uploads where you were the only person who made changes and were also
  the uploader.  Conventionally, one omits the author notation in that
  case since it's the common case that the uploader made all the changes.
  And it keeps the changelog a bit shorter.  I went back and removed those
  annotations.

I tagged the debian directory, but it looks like there are no tags for the
last few uploads.  Dunno if it's worth going back and retroactively adding
those tags.

> Btw, the version number in changelog maybe should be modified to include
> a date, so that the real gss-1.0.0 upload will be newer.  I'm not sure
> how to best do that, 1.0.0~20100329-1?

Yes.  Or ~git20100329, but the "git" part isn't really needed.

> On the other hand, maybe uploading 1.0.0-1 to experimental now and then
> 1.0.0-2 to unstable later works just as fine.

Note that if we'd done that, both would have had to use the same upstream
tarball.  You can't change upstream tarballs without changing the upstream
version, even moving between archive suites.  So that only works if using
the final 1.0.0 tarball release.

Of course, in this case, it doesn't matter since I didn't get the upload
done yesterday.

> If you have any comments (even stylistic) on the packaging code, please
> let me know, as I'm still learning debian packaging.  I'm co-maintaining
> the gsasl debian package in git and have learned to appreciate that, so
> possibly one improvement would be to move to git for gss & shishi too.

I would love that.  My documentation for how I structure my packages is
at:

    http://www.eyrie.org/~eagle/notes/debian/git.html

If I were you, I'd use the upstream Git development repository to hold the
packaging as well and just use a separate set of branches.  There's a
section in that document about how to set that up.  I find that very
convenient when working with packaging alongside upstream development.

Of course, that would mean giving anyone who's helping with the packaging
access to the upstream development repository, which you may not want to
do, or merging patch sets from people.

> The packaging uses CDBS and I'm not sure that is considered the best
> packaging tool any more (or if it ever was), so switching to something
> else would be another option -- but I don't know to what.

I really like debhelper 7 with rule minimization and overrides.  The
corresponding debian/rules file for the current GSS package would look
something like:

#!/usr/bin/make -f

DEB_HOST_ARCH  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)

%:
        dh $@

override_dh_auto_configure:
        dh_auto_configure -- --with-po-suffix

override_dh_auto_test:
ifeq (,$(filter $(DEB_HOST_ARCH),mips mipsel))
        dh_auto_test
endif

override_dh_auto_install:
        dh_auto_install
        cd doc && $(MAKE) install-ps install-pdf install-html DESTDIR=debian/tmp

override_dh_compress:
        dh_compress -Xgss.pdf

I don't remember if the version in shlibs is automatically updated based
on the information in the symbols file or if you still need an override
for dh_makeshlibs as well.

The advantage of using this method over debhelper is that all the
individual programs being run have man pages that document what they do,
and you can set DH_VERBOSE to 1 in the environment to see exactly what
programs are run in what order.

-- 
Russ Allbery (address@hidden)               <http://www.eyrie.org/~eagle/>