Russ Allbery <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> 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 [email protected] http://lists.gnu.org/mailman/listinfo/help-gss
