Re: Debian packages for 0.0.18 ready

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> Hi!  I've created Debian packages for GSS 0.0.18.  The Debian package
>> sources is on Savannah:
>
> I finally got a chance to look at this.  Sorry about the delay.

Thanks!

> Note that a build with a current unstable chroot will produce:
>
> W: gss-doc: install-info-not-called-with-section-option
> N:
> N:   It is a good idea to specify a section for the location of your
> N:   program; this is done with the --section switch. To determine which
> N:   section to use, you should look at the info dir file on your system
> N:   and choose the most relevant (or create a new section if none of the
> N:   current sections are relevant).
> N:   
> N:   Note that this warning is spurious in case your info file contains an
> N:   appropriate INFO-DIR-SECTION (@dircategory in Texinfo sources).
> N:   
> N:   Refer to Policy Manual, section 12.2 for details.
>
> This is a spurious problem at this point; dh_installinfo no longer adds an
> explicit --section argument because install-info figures it out by itself.
> I'll fix lintian.

Oh, right.  I suppose that ideally lintian would check that the info
file contains @dircategory etc if --section isn't given.

> The only other concern that I have is that the shared library package
> includes locales, which is going to get us into trouble when the SONAME
> changes.  A libgss1 package should be co-installable with libgss0 for
> transitions, but when they both contain locales, they're going to
> conflict.  For shishi, we added a shishi-common package to deal with
> this.
>
> I don't think this is an immediate concern, since libgss is some distance
> off from an SONAME change.  I've gone ahead and uploaded the package so
> that it can start sitting in NEW, and we can poke at the locales later on.

Good catch.  I wonder if there is some policy or anything on where to
store translations?  It seems like this would come up for many
packages, and I don't recall reading anything about it.

I wonder if the shishi-common approach handles soname changes well
anyway.  I mean, consider if there is libshishi0 and libshishi1.
libshishi0 might be version 0.4.0 and thus depend on shishi-common >=
0.4.0.  libshishi1 might be version 0.8.0 and thus depend on
shishi-common >= 0.8.0.  libshishi0, libshishi1 and shishi-common
(0.8.0) can be installed at the same time.  However, the translations
for libshishi1 0.8.0 might have changed compared to libshishi0 0.4.0,
which would break translations for libshishi0, which may be serious
for some users.

The only solution I can see is to change the gettext domain when the
soname changes, and have libgss0-common and libgss1-common which
wouldn't conflict.  That may cause problems for the translation
project, though, I'm not sure.

I'm not an gettext expert, perhaps there is some other way to have
multiple versions installed.  Perhaps I could ask Bruno if there is
some best practice from the up-stream point of view on this...

> Please note that given the proximity to the release, it would not surprise
> me for completely new packages to be left in NEW for quite a while, and
> this is too late in the release cycle to expect to get gss into etch.

Ok, no problem, I suspected something like that might happen.

Thanks,
Simon