Russ Allbery <rra stanford.edu> writes:
> Simon Josefsson <jasextundo.com> 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
_______________________________________________
Help-gss mailing list
Help-gssgnu.org
http:/
/lists.gnu.org/mailman/listinfo/help-gss
|