F-10 joyride vs 8.2 - getting fixes upstream.

[Peter Robinson]

>> I've started looking through the various packages that have been
>> pulled into joyride as part of the upgrade to Fedora-10 and reviewing
>> packages to see what differs from upstream, 8.2 and various other
>> olpcX packages. I'm aware of a number of packages that have been
>> pulled in due to differences in the packages between the old olpc3
>> branch and upstream
>
> So what's your view on how we should handle this?

Inlined below but the problem we have at the moment with things pretty
locked down in preparation for Fedora-10 final the changes and fixes
we get in are being held in the updates queue (like the ones I fixed
yesterday).

A large chunk of the differences are already upstream in Fedora 10.
The rest I'm prepared to run with as much as possible and I'm sure
gregdek, jkatz and others on the fedora-olpc are there to help me out,
plus of course the no doubt copious advice from this list ;-)

The reason I propose this while might be a bit more work now it means
that overall fedora mainline will end up assisting in the majority of
the work.

> You already detailed your views on packages where we actually modify
> the upstream code, such as totem-pl-parser: we should time (maybe a
> lot of it) trying to fix the upstream code so that they accept our
> change. I don't know how this will fly for already-overworked OLPC
> employees, but for me, I can work with that.

The totem-pl-parser is the harder style to deal with as we need
upstream totem project. These are the ones that are going to take
longer to deal with and we'll probably have to fork for this release
cycle.

> What about when we just change the dependencies? For example,
> SDL_mixer. Dennis already forked it, but let's pretend he didn't. What
> would be the ideal process for us to go through while working with
> Fedora?

These ones are much much easier to fix as its within the Fedora
project. We'll issues we'll have is with the more unresponsive
developers but there are ways to deal with those. I'm quite happy to
deal with these ones, log bugs, and even make the changes required in
conjunction with the package maintainers.

There's a couple of ways it can be dealt with. Someone can file a bug
an link it against the tracker bug so I can chase. Or to flag them to
me and I'll file the bug and chase. I already have done some of these.

> By the way, one of the original aims of OLPC was to get the OS down to
> 100mb (compressed). So this is going to be a painful, ongoing battle.
> But thanks a lot for your help :)

I figured there would be some sort of aim like this. Where are we on
this aim of the 100 meg with say the 8.2 release? Looking at the
correlation between the different releases below it looks like the 8.2
release was the smallest and as we stand we're not that much bigger
than update_1. But I suspect that is the sizing is based of a bunch of
rpms as opposed to install size. Remove just perl I we'll be below
update_1, from there I think it should be achievable to get the size
down to 8.2 in a pretty reasonable time.

http://dev.laptop.org/~bert/8.2-pkgs.html

BTW is there a live-cd or VM image download of joyride? I would like
to run one up on a VM environment where I can run some RPM dep hacky
scripts against the rpm install.

Peter