Re: Debian upload of gss 0.1.0

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

>> Looking at the package contents, libgss1 needs to conflict with libgss0
>> because (sigh!) the gss.mo files.
>
> Now's probably the time to move those files out of libgss1 into a separate
> support package.  This is required by Policy 8.2 for exactly this reason:
>
>     If your package contains files whose names do not change with each
>     change in the library shared object version, you must not put them in
>     the shared library package. Otherwise, several versions of the shared
>     library cannot be installed at the same time without filename clashes,
>     making upgrades and transitions unnecessarily difficult.
>
> I think the right thing to do is to move them into a separate package that
> conflicts with libgss0 and then have libgss1 depend on that package.  The
> dependency resolution should then sort everything out.  The next time
> there's an upgrade, people who have both libraries installed for the
> transition may get the wrong translations for the older library, but
> that's a relatively minor problem.

Ah, thanks for the pointer.

I have noticed another solution to this problem that is being used: in
the gnutls debian package there is a patch to make the gettext domain
use the same suffix as the shared library version.  So the files will be
gnutls26.gmo etc for the libgnutls26* debian package, instead of
gnutls.gmo, and any future libgnutls27* debian package can use
gnutls27.gmo and there will not be any conflict.  The translation
messages for each individual shared library package version will also be
correct.

Do you see any problem with that solution?  It would also avoid the need
for another small debian package, but it could have other negative
consequences that I haven't thought of.

I'm thinking about talking to the gettext people about making this an
officially recommended solution to deal with translations of multiple
concurrently installed shared libraries.  I could use some of my
upstream packages as a place to experiment with it as well.  But I'm not
convinced yet that it is the best solution.

Anyway, the other choice is (as you suggest) to create a new package
gss-i18n to hold the *.gmo files.

/Simon