[Yum] Progressive updating

Daniel Veillard veillard at redhat.com
Fri Sep 24 09:08:43 UTC 2004


On Thu, Sep 23, 2004 at 07:59:55PM -0400, seth vidal wrote:
> On Thu, 2004-09-23 at 19:09 -0400, Daniel Veillard wrote:
> >   Why this is badly needed:
> > 
> > ------------------------------------------------------------------------
> > automake 100 % done 116/477
> > error: unpacking of archive failed on file /usr/share/automake-1.9/Automake/Channels.pm;41535548: cpio: write
> > authconfig 100 % done 117/477
> > error: unpacking of archive failed on file /usr/lib/python2.3/site-packages/authconfigmodule.so;41535548: cpio: write
> > Segmentation fault
> > [root at localhost ~]# df
> > Filesystem           1K-blocks      Used Available Use% Mounted on
> > /dev/hda7              5039560   5039560         0 100% /
> > ------------------------------------------------------------------------
> > 
> >   We should never have 500 packages single transaction, nor the 500MB
> > /var space used for said packages needed by that transaction.
> > I'm sure this 500 package transaction could have been replaced by hundred
> > of smaller transactions where:
> >    - the amount of disk space required is smaller
> >    - the risk of damage due to a failing transaction is limited
> >    - current transaction and download of the next packages could be 
> >      parallelized
> >  
> >  Agreed, I didn't put code on the table, just the ideas so far.
> 
> two questions:
> 1. does up2date do anything differently for this interaction?

  no up2date does teh one big transaction thing too.

> 2. I'd be curious, as an interim step, to work on calculating complete
> subsets and displaying them as options for starting.
>   - so if a user runs yum update they could alternatively get bac:
>    - there are more than N packages in this update you might consider
> breaking up the update into the following commands
> 
>  and displaying the transactions needed to break it up.

  Makeing the UI complex would IMHO add nothing, except confusing the
user. Doing the big split precomputing it etc is likely to take more time
and resources.

> If you've got sample code that you think will move this in a direction,
> I'm all ears.

  yeah I know. I will have a hard time working on it before FC3 get freezed
unfortunately. On the other hand I implemented this once already. 

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



More information about the Yum mailing list