Re: Handling of libvte / vte-common and package name change

[Loïc Minier <lool+debian@via.ecp.fr>]

 I'm afraid I didn't receive much feedback on this, and while I know the
 most complete solution involves patching both the textdomain name and
 the path to the termcap files, I prefer keeping my hands out of this.
 I will upload a package dropping the versionning of the libvte-common
 dependency altogether; this decision is based on two technical facts
 which I didn't have when I started the discussion:
 1) only the translations not matching the templates will break, this
    won't cause any buffer overflow or format string problems as gettext
    won't replace the text if the templates don't match; so no risk of
    breakage due to translations, but some translations will be out of
    date and new or old text might be displayed in english
 2) the termcap files did not change since 2002; these are deeply
    frozen, beside I couldn't figure a scenario where termcap files
    would be changed incompatibly; termcap files are supposedly copied
    in a lot of ways and may even live outside of the vte package, so
    IMO vte has to keep compatibility with previously published termcap
    files

 I know this isn't perfect, but it will save us patch work, and I'm
 quite sure we would forget to patch new bindgettextdomain() calls
 between new upstream releases, or references to the termcap files as we
 don't have a per-source "new upstream release" procedure to follow.


 This will permit installing unstable's libvte + libvte-common aside of
 experimental's libvte.

-- 
Loïc Minier <lool@dooz.org>