make console colors use update-alternatives system

For console-setup, it's just a matter of hooking /etc/vtrgb into the update-alternatives system.

For new, it's considerably more complicated. I have rewritten the color loading scheme to optionally read the palette from file, and if not found, to fall back to the default scheme. Working (albeit rough) patch attached.

Updated newt patch attached, and tested. Working well!

This bug was fixed in the package console-setup - 1.57ubuntu13

---------------
console-setup (1.57ubuntu13) natty; urgency=low

  * debian/rules, debian/console-setup.postinst: use update-alternatives
    to allow other packages to install different console color values,
    LP: #737948
 -- Dustin Kirkland <email address hidden> Fri, 18 Mar 2011 22:02:12 -0500

And the console-setup patch.

This bug was fixed in the package newt - 0.52.11-2ubuntu4

---------------
newt (0.52.11-2ubuntu4) natty; urgency=low

  Fixes for LP: #737948
  * debian/patches/800_ubuntu_skin.patch,
    debian/patches/801_configurable-palette.patch:
    - drop the hardcoded color changes
    - instead, read color values from /etc/newt/palette, if readable
  * debian/libnewt0.52.install, debian/libnewt0.52.postinst,
    debian/palette, debian/palette.ubuntu, debian/libnewt0.52.dirs:
    - install the default palette, and an ubuntu palette, use the
      update-alternatives system to set
 -- Dustin Kirkland <email address hidden> Fri, 18 Mar 2011 21:56:08 -0500

Is it really a good idea to have a file in /etc be a symlink into /usr? Now it looks as though it's sysadmin-editable, but if they change it then it will be overwritten on the next upgrade.

I think it would be a good idea to slow down and discuss these types of changes before uploading. Alternatives can be tricky beasts and it's worth getting them right first time.

Dustin and I spent a couple hours talking about this yesterday. This is the best option we came up with as a short-term fix to make newt's color palette configurable, instead of hard-coded into a C function (to avoid forking the whole package when the patch to newt is only a few lines). Longer-term, we want to talk with the upstream newt developers about breaking the color palette out into a config file, how they'd like to do it, and what they'd be likely to accept upstream. But, it didn't seem fair to subject the Kubuntu folks to an aubergine command-line (or hold Ubuntu on the default palette) while that conversation is happening.

I'd suggest defaulting to the default we had at feature freeze or reverting the and trying again in oneirc would be better.

On Sat, Mar 19, 2011 at 08:46:48PM -0000, Allison Randal wrote:
> Dustin and I spent a couple hours talking about this yesterday. This is
> the best option we came up with as a short-term fix to make newt's color
> palette configurable, instead of hard-coded into a C function (to avoid
> forking the whole package when the patch to newt is only a few lines).

I'm not objecting to that part of it. My point was more that, at
minimum, the alternative target needs to reside in /etc, not /usr -
otherwise the package effectively violates policy for /etc.

cjwatson wrote:
> the alternative target needs to reside in /etc, not /usr -
> otherwise the package effectively violates policy for /etc.

Good idea.

scottk wrote:
> I'd suggest defaulting to the default we had at feature freeze

That's the intention, the default palette is the original one, and palette.ubuntu is the customized colors. (I expect that's what upstream will want too.)

On Sat, Mar 19, 2011 at 5:07 PM, Colin Watson <email address hidden> wrote:
> I'm not objecting to that part of it.  My point was more that, at
> minimum, the alternative target needs to reside in /etc, not /usr -
> otherwise the package effectively violates policy for /etc.

Great point, Colin. Sorry about that. I have filed and am fixing Bug
#738992 now!

--
:-Dustin