Re: [zypp-devel] separating rpm download and installation
Hi, Michael Andres wrote:
On Mon, Oct 02, Duncan Mac-Vicar Prett wrote:
On Friday 29 September 2006 14:45, Martin Vidner wrote:
Hi,
all CLI tools over RPM have the ability to separate downloading and actual installation of RPMs - typically the admin wants to download all patches overnight in a cron job and then review them before installing manually.
Does libzypp support this usage? If not, do we have a bug/feature open already? With Michael Andres we discussed the design some time ago, concluding why Commit is tied to target. Commit should be an abstract class, using the same rpm facilities, so we could switch it on the flight for a FakeCommit or a just download to a dir commit.
Commit is probabely not the right choice.
What we want is some kind of source sync. Enabling the source creating a mirror repository on the local disk. So the source can mirror the repo via cron and run from the local repo when used for install/update.
To mirror a repo is a huge task when it comes to disk space and network traffic (and mirroring tools should IMO be separated from package management like install/remove/upgrade). Downloading only resolvables needed for the operation in question before actually doing something with them is something different. This would e.g. enable us to avoid ending up with broken dependencies if a problem with downloading occurs on a half-way while upgrading several interdependent packages. Another example of using such feature is similar to the one mentioned in the original post: download all needed resolvables for an operation while i'm away so that i can check and run it again and watch it as it instantly executes (no need to wait for downloads now). I propose to separate the download and installation by default, and provide an option to do an "instant installation" in clients.
Additionally the local mirror can be offered to other machines in the local net as source.
We could think about some "partial mirror" as well, where the source just keeps downloaded packages/deltas/patches/.. on the disk. Refreshing matadata would then additionally remove outdated stuff from disk and keep stuff still uptodate.
If the above is doable with a "partial mirror", i'd vote for it.
That's what we could easily offer as a per-source soloution.
Next would be a common cache, in case you have many sources with same or overlapping content. Some PackageProvider class would then check the local cache to see whether the matching package is already there.
jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
I think this can be solved in the following way. As Michael stated once, our transaction object is just a pool object. Instead of having commitas a method of target, we have to create a abstract class taking a pool and create different implementations of it. Having a pool commit that only logs is very useful for unit tests. So we could have one that takes a Pool and a directory, and it just downloads (if you use Fetcher, and configure Fetcher with a cache directory, you get cached rpms for free), you can have another one that just logs, and another one that downloads and install. As we dont want to replicate code in the Committer that downloads, and the one that downloads and install, we could find a pattern to make them chainable or composite (like Java Stream classes) Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (2)
-
Duncan Mac-Vicar Prett -
Jan Kupec