[Feature Request] OEM config should offer to purge extra language packages or offer command line option to do so

>In the event that more than one language pack is preinstalled, I think
>an option should be added to the end of the OEM config wizard to remove
>extra language support. This should be pre-selected, but disableable by
>OEMs who would prefer it not turned on by default.

This is an excellent idea. The additional updates for unnecessary languages
eat up bandwidth, further burden distribution servers, and inconvenience the
customer at update time.

We currently mitigate (somewhat) the problem in two ways: First, we ask the
customer at order time what languages are desired, but that's not always
possible to do, especially in a retail environment. (We also find that some
customers are a tad defensive or subtly evasive when responding.) Second, we
ship a DVD with addtional language packages relevant for the target market,
but that's not an optimal customer experience. I'm not even sure that anyone
ever looks at the documentation or the DVD anyway.

>A small mouse over should explain a little better what the ramifications
>would be as well as if possible the amount of disk space that would be
>freed by removing extra language support.

I like the concept, but a mouse-over would over-complicate things. (Not
everyone is physically able to use a mouse, and not every consumer computer
design contemplates one.) A concise sentence or two of explanation would
appropriately and neatly fit in the existing dialog box.

IMHO, the emphasis of that message should be on speeding up the update
procedure and on conservation of network and server resources. The addtional
hard drive space is trivial compared to the size of hard drives these days.
Everyone hates waiting for updates, however, and no one likes paying for
more bandwidth.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://start.iycc.net

The request here is have a button or method in oem-config to remove all other language packs except for the one that the user chooses.

There are some issues here, though. What if you have a user who chooses english, but has a secondary user of the machine who can only speak chinese.

Perhaps it should allow the user to have the option to:
                - remove all other languages
                - choose any other languages then the ones they have choosen to keep on
                   the system

The justification here is to ensure the 9.10 includes this feature.

The request is to allow for a button or some command line method of removal of all extra lanuage packs. For Dell in this case a user is hit with 800 or so updates after install, most related to lanuage packs.

Also new offerings of smaller gig (8 for example) SSD drives are coming soon. So to purge all these packs would clear a lot of space, as well as allow for Dell to have one global image.

Another approach is to install (via oem-config or other) only the language packs for the language(s) the user is interested in.

For example, the installer used by the Dell Mini systems (9, 12, 10) creates an on-disk pool containing language packs. There is a tool called language-installer that runs at the end of oem-config; language-installer installs the appropriate packages out of the pool based on the user's selection in oem-config, then deletes the pool. This way only the requested languages get installed, providing a much smaller disk footprint and eliminating the flood of language pack updates. This setup has been used successfully on systems with as little as 4GB SSD (the Dell Mini 9).

I expect that either of these possibilities will be easier once
oem-config is merged into ubiquity, since then we'll be able to take
advantage of code that already exists in ubiquity to do this kind of
thing. Michael Terry has been working on this.

I'd lean toward the latter selection as long as some granularity could be applied in that the on-system repo could be conditionally copied at install time. For Dell factory proper, they would already all be on the recovery partition anyway, so just need to make sure that apt knows they are there.

If the latter solution was selected, that would also mean the livefs from the CD could be used on the DVD again too.

On Tue, Jun 30, 2009 at 09:43:04PM -0000, Mario Limonciello wrote:
> I'd lean toward the latter selection as long as some granularity could
> be applied in that the on-system repo could be conditionally copied at
> install time. For Dell factory proper, they would already all be on the
> recovery partition anyway, so just need to make sure that apt knows they
> are there.

Yes. You could copy the on-system repository with a hook script, or we
could have ubiquity copy over some debs in OEM mode and generate indices
(a bit tricky but technically possible).

> If the latter solution was selected, that would also mean the livefs
> from the CD could be used on the DVD again too.

Really? The point of having an expanded live filesystem on the DVD was
at least in part so that the live system could be translated in all
possible languages even before installation.

This is being addressed by: https://wiki.ubuntu.com/FoundationsTeam/Specs/KarmicOEMConfigImprovements. It doesn't look like we can have this in place for 9.10, but waiting on confirmation from developers.

Colin, did we end up getting this in? Or did we decide to defer to Lucid?

This will not make the Karmic release, however it is being considered for Lucid. See "full specification" link in the blueprint: https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-oemconfig

This issue was dissussed at UDS-l conference. The proposed solution was to be made through a new oem iso image & the oem-config that comes along with it. Colin Watson took lead at the confrence though there currently is no blueprint for it.

Details where still to be worked out.

Here is the blue print for the oem iso image. This is what is proposed that will resolve this issue.
https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-oem-dvd-iso

Trying to reproduce the behavior from Network Manger has proved not very easy. In the code this happens when network manager is trying to set the host name.

I have summited a patch upstream. To at least fix the invalid hostname file. I have attached patch below.

Talking this issue over with Mario. It is highly unlikely we will be able to run into this issue with network manager given the oem-config fix, as well as the inability to have network manager demonstrate the behavior hacking up an Ubuntu install.

With the fall back fix making it's way upstream, we will have it for the Lucid time frame which is acceptable.

Given this can now completely close this bug out.

Nevermind the last 2 posts they where to the wrong bug!

This bug was fixed in the package ubiquity - 2.2.13

---------------
ubiquity (2.2.13) lucid; urgency=low

  [ Evan Dandrea ]
  * In oem-config, support removing packages that were not part of the
    base install and are not needed in the final system by preseeding
    oem-config/remove_extras to true (LP: #315644, LP: #553184).

  [ Roman Shtylman ]
  * Kde_ui:
    - fixed (LP: #550466) (LP: #550472) using kmessage box for quit dialog
    - fixed (LP: #540202) hide widgets until translated
 -- Mario Limonciello <email address hidden> Thu, 01 Apr 2010 11:51:01 -0500

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305471

karmic has seen the end of its life and is no longer receiving any updates. Marking the karmic task for this ticket as "Won't Fix".