[Yum] Progressive updating

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux