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

[Sayamindu Dasgupta]

On Sat, Jun 28, 2008 at 12:20 AM, Erik Garrison <erik at laptop.org> wrote:
> 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?


Something that comes to my mind is the potential memory usage issues
some people have been seeing while trying to use yum. A description of
one such case is in
http://www.nabble.com/Re%3A-Moving-to-metacity-with-composition-(was%3A-Preparing-for-the-feature-freeze)-p17621634.html

Thanks,
Sayamindu


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