FIltering out languages via kickstart

[Sayamindu Dasgupta]

CC += devel

On Thu, Jul 9, 2009 at 5:38 PM, Daniel Drake<dsd at laptop.org> wrote:
> On Thu, 2009-07-09 at 16:23 +0530, Sayamindu Dasgupta wrote:
>> Well, we can have an initial set of language packs pre-installed
>> (taking the list from --instLangs). I am trying to set up a repository
>> with RPMs generated from Pootle (similar to what we have today, but
>> instead of self extracting archives, the packs will be RPMs). Does
>> that sound like a viable option ?
>
> I can still see some problems...
>
> You're working towards having these installable from a customization
> stick, right?
>
> On the customization stick, we would then want some way of
> differentiating language pack RPMs from other RPM packages - at least I
> don't think we want to give the ability to install RPMs in that fashion
> where we haven't before.
>

I'm not sure how we can differentiate RPMs - can we use a different
signing key, to sign the RPMs, for instance ?

> Also, do these RPMs write outside of /home? If so, you break the fast,
> incremental olpc-update method.
>

Hmm - I do agree that this breaks upgrade.

> But one advantage of using RPMs is that you could push the following
> process to deployments:
>  1. install F11 on an x86 computer
>  2. run some simple commands to install livecd-creator and download our
> spec file
>  3. modify the spec file, adding in your language pack RPM
>  4. run a command to make a build
>
> and then they have their own *clean* build with their own language pack
> as a result.
>
> One disadvantage is that deployments (with secured laptops) that are not
> able to sign their own builds would be excluded..but this has always
> been the case. And I think the OLPC position at the moment is "big
> deployments should sign their own builds; small deployments should have
> security disabled"
>
> Might be worth a larger discussion with Chris and Ed.
>

>From what it seems (except for the advantages you have described) - it
may make sense to use the older system of zip files (or have, even
translation bundles) and install it under /home/olpc (that can be
easily done, since the patch allows to specify the directory, instead
of hardcoding it, as in Ubuntu). This will

a) Make translations persist across updates
b) Require minimal changes to the existing customization key mechanism
c) Require minimal changes to the existing language pack building mechanism
d) Let users modify/enhance the translations themselves, via a Sugar activity


Of course, we would miss the bells and whistle that come with RPMs,
but I think this is better than overwriting and moving around existing
MO files (which is what we do now).

Thanks,
Sayamindu


-- 
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]