challenges of distro switching
tiagomnm at gmail.com
Sun Jun 6 10:26:07 EDT 2010
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
> > 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
> 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.
> 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
> 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
> > available after 12 months(?), which from what I've seen is around the
> > 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
Sorry about that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel