Re: libgss1 -> libgss2 transition?

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

> 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.

No problem, thanks!  I'm leaving for vacation tomorrow, and GSS was
holding up my GNU SASL release and I wanted to get it out ASAP, so
that's why I didn't wait with releasing GSS 1.0.0.

> 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.

Right, ftp.gnu.org will be the future site for all non-alpha releases.

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

Ok.  There is no lintian warning about that. ;)

> * 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.

Aha, I wasn't aware of that.  Will avoid it in the future.

> 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.

It is probably not worth the time...

>> 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.

I'll try that sometime.

>> 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.

Ok.

>> 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

I've read that before, and it is useful.  I didn't get your git-pbuilder
stuff to work, though, so I am using this short script 'git-pdebuild':

#!/bin/sh
exec git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' 
--auto-debsign"

I don't recall why your script didn't work for me..

> 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.

I'll think about that -- I suspect I'll prefer to put the debian
specific stuff in another git repository instead of the upstream one.
I'm not sure I trust all the git/debian tools to not mess up my
repository yet.  There is also size/speed concerns.

>> 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.

Ok, I think we should switch to this after squeeze.

/Simon