[Pkg-urxvt-maintainers] Bug#848284: ping: please take over rxvt and migrate rxvt-unicode to 256

[Adam Borowski]

On 2016-12-16, I wrote:
> Because it's a shame to ship terminals incapable of UTF-8 when a
> fully-capable fork exists, please produce dummy transitional packages
> that depend on rxvt-unicode-256color:
> * rxvt
> * rxvt-unicode
> * aterm

As I filed this just before Stretch's freeze, and you didn't act
immediately, the freeze precluded us from killing old rxvt.  It'd be nice if
you could do so for Buster.

> This has been OKed by rxvt's maintainer, rxvt-unicode is produced by your
> source, aterm is orphaned.  All of these come from the same codebase
> origins, and none have drastic changes that would make users complain.

aterm is done (even was in time for Stretch).

> As for why -256color, that's a separate issue.  There's no real way to
> detect lack of 256 color support

rxvt and rxvt-unicode are the only terminals with 88 color.  Thus, getting
rid of them (replaced by rxvt-unicode-256color), would mean any terminal can
take 256 color codes and do a reasonable thing.  In theory, the palette for
both 88 and 256 color is supposed to be settable, but 1. not every terminal
allows redefining (osso-xterm, linux console, kfreebsd console, ... don't),
2. the vast majority of programs just assume the default palette
unconditionally.  So this ship has sailed, and let's better make it work.

I think, though, that instead of migrating to rxvt-unicode-256color, it
might be better to take over rxvt, make it the primary package, and make all
other variants be dummy transitionals for it.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.