Handling of libvte / vte-common and package name change

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

        Hi,

 libvte9 and libvte4 are not parallel installable due to the versionning
 of the vte-common dependency.

 vte-common carries:
 - locale data
 - a termcap file

 I've discussed options on debian-devel@ for handling locale data, but
 not the problem of the termcap file.

 When I first considered libvte-common, I thought we should simply drop
 the package, and either:
 1) rename the /usr/share/locale/*/vte.mo into
    /usr/share/locale/*/libvte$soname.mo and ship these in
    libvte$soname.mo
 2) or keep the */vte.mo files, but add replaces

 (2) permits co-installability, but there might be missing translations)


 While a patch for 1) would not be too hard (basically patch
 bindtextdomain() and perhaps dgettext() calls to use a name passed via
 CFLAGS instead of PACKAGE), patching the path to the termcap file might
 be more complex / intrusive.

 Also, while there is no risk in using Replace for the translations,
 there might be some risk in doing the same for the termcap file.

 So, what do people think of the best way to handle the termcap path?
 Is it used in other sources than vte?


 My position is currently that it would be safer to patch the termcap
 *DATADIR* than the termcap file itself, for example using
 "/usr/share/libvte$soname/termcap/xterm" (and not using
 "/usr/share/vte/termcap/xterm-$soname"), but I wonder whether we should
 provide some backward-compatibility symlinks (perhaps via
 "alternatives"?) for the old pathname.


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