make console colors use update-alternatives system

Bug #737948 reported by Dustin Kirkland  on 2011-03-19
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
console-setup (Ubuntu)
Wishlist
Dustin Kirkland 
newt (Ubuntu)
Wishlist
Dustin Kirkland 

Bug Description

Binary package hint: console-setup

Derivative distributions might want to change the console and newt colors without having to recompile or fork packages. Use the update-alternative systems to install color and palette configurations.

Related branches

Dustin Kirkland  (kirkland) wrote :

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

Changed in console-setup (Ubuntu):
status: New → In Progress
Changed in newt (Ubuntu):
status: New → In Progress
Changed in console-setup (Ubuntu):
importance: Undecided → Wishlist
Changed in newt (Ubuntu):
importance: Undecided → Wishlist
Changed in console-setup (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
Changed in newt (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
Dustin Kirkland  (kirkland) wrote :

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.

Dustin Kirkland  (kirkland) wrote :

Updated newt patch attached, and tested. Working well!

Launchpad Janitor (janitor) wrote :

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

Changed in console-setup (Ubuntu):
status: In Progress → Fix Released
Dustin Kirkland  (kirkland) wrote :

And the console-setup patch.

Launchpad Janitor (janitor) wrote :

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

Changed in newt (Ubuntu):
status: In Progress → Fix Released
Colin Watson (cjwatson) wrote :

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.

Allison Randal (allison) 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). 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.

Colin Watson (cjwatson) wrote :

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.

Allison Randal (allison) wrote :

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

Dustin Kirkland  (kirkland) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers