OLPC-Update + RPMs WAS:Re: OLPC XO Opera browser as Sugar activity

[Erik Garrison]

On Fri, Jun 27, 2008 at 01:23:46PM -0400, Ian Daniher wrote:
> What's the logic for having updates erase all manually installed RPMs?
> A couple of Support-Gangers and myself were talking about ways to remedy
> this.
> We came up with the following:
> 
>    - alias "rpm -i $FILE" to "rpm -i $FILE & cp FILE $HOME/.rpms$/FILE" with
>    a script on update that runs "rpm -i $HOME/.rpms/*"
>    - have a script that constantly monitors $HOME/.bash_history for "yum
>    install $PROGRAM" formatted files, then echos the name of $PROGRAM to
>    $HOME/.rpms/installed, but removes it from that list if/when it sees "yum
>    remove $PROGRAM" On update, yum install $(cat $HOME/.rpms/installed) is run.
>    - rpm -qa > $HOME/.rpms/clean could be run on install
>    - rpm -qa > $HOME/.rpms/custom could be run before update
>    - a simple file compare program (python or python-parsed diff output)
>    would be used to generate a file with which yum install $(cat $FILE) could
>    be used
> 
> thoughts?
> 

We should move away from using olpc-update to upgrade systems.  We
should not implement this or any hack to preserve manually installed
rpms through olpc-updates.

Existing package managers (e.g. apt, rpm) do exactly what we want and
more.  Furthermore they are extensively tested and well documented.  Why
have we locally manufactured and promoted the square wheels of
olpc-update and copy-nand?

We already have yum installed on the XO.  Why are we not using it to
implement software update procedures?

There are several reasons which occur to me:

  1) OLPC software developers mostly use apt-based systems and have been
slow to adopt rpm-based ones.

  2) Many have expressed frustration with yum, the user-friendly package
manager interface to rpm.  Even simple operations (yum search) will
download megabyte-order header files every time these headers change
unless yum is instructed not to (with the '-C' flag).  More
problematically, rpm refers to dependencies on a file-by-file level,
instead of package level, increasing the space and processing complexity
of rpm package management operations relative to deb-based tools, which
track dependencies on a (coarser) package level.

  3) The tools we have created work well enough to not halt software
development and deployment.  Therefore there has been insufficient
pressure to move away from them.

I don't think any of these reasons outweighs the benefits of migrating
to rpm/yum for software distribution.

Objections?  Thoughts?

Erik