help-gss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian packages for 0.0.18 ready


From: Russ Allbery
Subject: Re: Debian packages for 0.0.18 ready
Date: Wed, 15 Nov 2006 01:10:55 -0800
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

Simon Josefsson <address@hidden> writes:

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

Yup, that's exactly the fix I just committed.

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

It's one of these library issues that's often honored in the breach, and
people don't notice until they have to do an SONAME transition.  Policy
currently is only explicit about binaries accompanying the library, not
random other files.  It could use more work in this area.  Maybe I'll poke
at that once I dig out from under the other three Policy threads I'm in
the middle of.

Plus, I don't think many libraries have translations.

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

I think it's probably acceptable to allow fuzzy translations for users of
the old library during an SONAME change; the normal expectation is that
the transition period will be short-lived as programs are recompiled with
the new library.

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

If they don't conflict, we could stuff them back in the library package
and reduce the total package count; they're not large enough to warrant
splitting out otherwise.  That's a thought; you could, instead of having
gss.mo, have gss0.mo and continue to append the SONAME to the gettext
domain.  I don't know about the translation project, though.

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

Sounds like a good idea to me.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]