Mailinglist Archive: opensuse-features (368 mails)

< Previous Next >
[openFATE 305624] Allow downloading all packages before installing
  • From: fate_noreply@xxxxxxx
  • Date: Tue, 23 Jun 2009 21:53:15 +0200 (CEST)
  • Message-id: <feature-305624-69@xxxxxxxxxxxxxx>
Feature changed by: Reza Davoudi (rd1381)
Feature #305624, revision 69
Title: Allow downloading all packages before installing

openSUSE-11.2: Candidate
Requester: Important
Projectmanager: Important

Requested by: Jiri Srain (jsrain)

Libzypp should allow to set a policy to first download all packages and
afterwards install all packages at once.
It should be considered whether to enable this policy under some
scenarios (e.g. makes sense for online update, but not for distro


- Suggestion for download failure handling from openSUSE-factory (url:

#1: Stanislav Visnovsky (visnov) (2009-01-28 15:56:51)
I see this as a pre-requisite for in running-system distribution
upgrade reliability.

#3: Robert Davies (robopensuse) (2009-01-29 16:56:54) (reply to #1)
Could this be better achieved by some general package cache-ing tool
that can serve a LAN, providing packages from HDD, DVD or http/ftp
download as appropriate? Upgrading by making a local copy of all
packages in somewhere like /var/cache is going to explode disk space
requirements. If the disk is nearly full, then both throughput and
fragmentation worsen. In degenerate case of single PC LAN, the server
can be run locally, which might ease the opposite policy of pipelining
downloads to accelerate install speeds when most rpm's are available
locally, but some need an update downloaded.

#4: Rajko Matovic (rajko_m) (2009-01-30 01:41:51) (reply to #3)
It could be, but here is the word about download of packages involved
in update before attempt to install them. It is just about improvement
of current workflow where some packages are already installed when come
to download error. This can have unwanted consequences to system, or
applications. In some scenarios it can render system unbootable, in
other package management will be rendered inoperational.
In any case to improve dependability of package management first
download, then install is needed feature.

#6: Robert Davies (robopensuse) (2009-01-31 14:07:54) (reply to #4)
I understand, but breaking the problem up, would make the logic
simpler, and be more flexible for other requirements, permit
interleaving of bandwidth & cpu limitted operations in parallel. Even
downloading first, doesnt' guarantee a needed package, will be
installable, unless you check all the signatures etc. Really the
reliable update problem, requires installing a package set as a
transaction, download first just avoids 1 class of errors, but if it's
implemented naively could cause problems for other ppl.

#7: Manuel Trujillo (toomany) (2009-02-02 15:47:03) (reply to #1)
I agree completly with you.

#9: Diederik van der Boor (vdboor) (2009-02-26 09:12:38) (reply to #1)
Agreed. I've broken my system once before with a dist-upgrade. Half way
the mirrors couldn't provide some packages (probably just got a
buildrev-upgrade) and I got stuck with an half-upgraded system. Had to
boot from CD, get the system bootable again and do rpm magic to find
all packages which weren't upgraded.
This just shouldn't happen, and downloading all packages first should
fix it too. Nowadays I always do a dist-upgrade from DVD as

#2: Stanislav Visnovsky (visnov) (2009-01-29 13:02:26)
A suggestion on openSUSE-factory mailing list was to continue
downloading all packages, deferring the errors until all that are
donwloadable are indeed on the disk.

#5: Jan Engelhardt (jengelh) (2009-01-30 15:26:32)
Both modes should be supported. Install-as-downloaded (like it does
today) for space-contrained systems, and install-after-download for
where there is enough space and/or the user enabled it.

#8: Jay Mistry (zmdmw52) (2009-02-15 09:15:05) (reply to #5)
I agree; (in addition to space-constraints), may also be relevant in
places that have limited/time-based Internet connectivity. For those
who (and many users don't require this) do not want/need latest desktop
effects, etc; it would make sense to have a cache (locally) of
executables (RPM's), that can be saved to backup medium (network
server, CD/DVD, etc) once a stable working system configuration is
obtained. This can be used as a 'local repo' for system file updates as
well as software (program) RPM's (similar to how the install DVD is
listed as a repo source).
For those that prefer to do or don't mind periodic Internet updates,
they can disable the former option.

#10: Pascal Bleser (pbleser) (2009-03-02 08:39:41)
You may note that this is how smart does it: it first downloads all the
required packages to disk (into /var/cache/smart/packages/) and then
applies the updates in a single RPM transaction, without resorting to --
Also, when the transaction fails, it leaves the downloaded packages
into the cache directory. And obviously picks them up from there when
available, and doesn't download them again. There is an explicit
command ("smart clean") to clean up the cache directory.

+ #13: Reza Davoudi (rd1381) (2009-06-23 21:49:00) (reply to #10)
+ smart is great in this feature but lacks other robust features : like
+ when i tried to install the new version of amarok with smart , it
+ downloaded the packages but when instaling said that there is a
+ conflict of file between an installed package and one of the installing
+ packages . i tried it with yast and it went smoothly.
+ maybe  yast ignores this minor file conflicts? :)
+ but i agree that a download and install later feature (or at list an
+ option to do so before installing ) would be great , especialy now that
+ there is many mirror problems and that yast sticks to one mirror for
+ every repository and retring ,doesnt change the mirror to a better one
+ .

#11: Cristian Morales Vega (reddwarf) (2009-03-05 10:20:10)
A problem with the current Install-as-downloaded system is that rpm
needs to be executed with "--replacefiles" (or something equivalent).
An install-after-download system should behave like Smart, checking
first if there two packages trying to own the same (but different)

openSUSE Feature:

< Previous Next >
This Thread