challenges of distro switching

[Tiago Marques]

On Sat, Jun 5, 2010 at 6:37 PM, Daniel Drake <dsd at laptop.org> wrote:

> On 5 June 2010 12:14, Tiago Marques <tiagomnm at gmail.com> wrote:
> > I built OLPC's kernel in Gentoo with no problems, which helped me a lot
> to
> > start. The rest works great.
>
> Perhaps we aren't talking about the same things. I'm referring to how
> we can build an image which would be suitable for OLPC 1:1 deployments
> at large scale, without introducing huge churn for existing
> deployments, without demanding a significant additional amount of work
> both now and ongoing.
>

We are talking about the same things, I was sharing my experience with my
usage but was more specific. That's why I later said that I could only think
of olpc-update, as I haven't been in contact with the rest. Sorry for not
being clear.


>
> I suspect you're only working with what is important for you. (i.e.
> you aren't using antitheft, you aren't pushing OS updates
> automatically to yourself, you aren't using the customization stick,
> you aren't customizing the Browse homepage, ...)
>
>
Exactly, thanks for being specific.


> > Can you be more specific of what more would break? I can think of
> > olpc-update but not much else unfortunately.
>
> Antitheft
> Activation
>
> A mountain of packages and their corresponding effects on the system,
> to think of a few: olpc-update, olpc-contents, ds-backup, bitfrost,
> dracut-modules-olpc, library, kbdshim, powred, runin, olpc-utils,
> switch-desktop, bootanim
> Several of those packages depend on Fedora-specific things that would
> need to be adapted.


Thanks. Now I have something to look into in my free time. I have wanted to
get some of those things to work on both XOs but didn't wanted to bother
anyone here. Would someone be willing to answer me when I have some
questions about those packages?


>

Various important bits of Fedora that we depend on - like their
> memory-backed rwtab file system.
>
>
That's a tricky one.


> New build system would be needed, replacing all functionality of
> olpc-os-builder
>
> It also invalidates many processes that myself and others have been
> training in the field, such as usage of rpm/yum, how to write spec
> files, etc.
>
> It would result in a range of different package versions being used,
> compiled against different dependencies, invalidating a lot of
> testing, creating divergance from XO-1.5.
>
> It means everyone working with OLPC at a suitably low level has to
> learn a new distro.


> > That's true but you're again limited to not having security fix or
> updates
> > available after 12 months(?), which from what I've seen is around the
> time
> > the image is ready for deployment.
> > I have no idea of the work involved in that, aside from what I read here.
> > From what I've read it could be worth it but it was just a suggestion.
>
> Generally not important for field deployments. In the cases where it
> is important, OLPC already has a mechanism (push a new RPM, maybe
> generated manually by OLPC, and do a new release).
>
>
I see. From feedback it seemed more important but if it isn't then it really
doesn't make much sense.


> I'm not discounting your suggestion to switch to another distro. Feel
> free to steam ahead with your efforts.
>
>
If I ever get the user side ready, I'll be sure to post here. Maybe it will
be useful sometime.


> I was solely talking about a simple way to keep the existing base
> available to XO-1 deployments. The thread that you hijacked was about
> Fedora.
>
>
Sorry about that.

Best regards,
Tiago


>  Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100606/5d7a6cfd/attachment.html>