Hi, 4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only. Fun, but why does the cached size outdo the overall size? Cheers, Pete
On Friday 2021-02-19 18:40, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
rm -rf /var/log/zy* zypper dup --debug-solver tar -cf pack.tar /var/log/zy* save that - preferably put to bugzilla - before you do anything else.
Am Freitag, 19. Februar 2021, 19:28:16 CET schrieb Jan Engelhardt:
On Friday 2021-02-19 18:40, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
rm -rf /var/log/zy* zypper dup --debug-solver tar -cf pack.tar /var/log/zy*
save that - preferably put to bugzilla - before you do anything else.
As Michael noted, I keep the caches on purpose, and share /var/cache/zypp/ packages with other machines, but those numbers are a bit different as well: ~> du -sh /var/cache/zypp/packages/ 199G /var/cache/zypp/packages/ Reveals the question, if libzypp takes available, but unrelated packages into account? Anyway: boo#1182513 Cheers, Pete
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Am Freitag, 19. Februar 2021, 19:28:16 CET schrieb Jan Engelhardt:
On Friday 2021-02-19 18:40, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
rm -rf /var/log/zy* zypper dup --debug-solver tar -cf pack.tar /var/log/zy*
save that - preferably put to bugzilla - before you do anything else.
As Michael noted, I keep the caches on purpose, and share /var/cache/zypp/ packages with other machines, but those numbers are a bit different as well:
~> du -sh /var/cache/zypp/packages/ 199G /var/cache/zypp/packages/
Reveals the question, if libzypp takes available, but unrelated packages into account?
Anyway: boo#1182513
Cheers, Pete
Wow, you must be keeping a lot of packages. I did a purge this morning and my zypp cache dropped from 10G to 4.5G. I basically do an rpm -q -a and then remove cache files not in that list. I've put a gist on github: https://gist.github.com/digitaltrails/cfd6617be9f0e5cfbdaaf951d4526aef The downside of purging off old rpm's is that I can no longer revert to older versions via the cache. For me that's not a problem, I only want an up to date cache for seeding another desktop. Cheers, Michael
Am Freitag, 19. Februar 2021, 22:34:43 CET schrieb Michael Hamilton:
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Am Freitag, 19. Februar 2021, 19:28:16 CET schrieb Jan Engelhardt:
On Friday 2021-02-19 18:40, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
rm -rf /var/log/zy* zypper dup --debug-solver tar -cf pack.tar /var/log/zy*
save that - preferably put to bugzilla - before you do anything else.
As Michael noted, I keep the caches on purpose, and share /var/cache/zypp/ packages with other machines, but those numbers are a bit different as well:
~> du -sh /var/cache/zypp/packages/ 199G /var/cache/zypp/packages/
Reveals the question, if libzypp takes available, but unrelated packages into account?
Anyway: boo#1182513
Cheers, Pete
Wow, you must be keeping a lot of packages. I did a purge this morning and my zypp cache dropped from 10G to 4.5G. I basically do an rpm -q -a and then remove cache files not in that list. I've put a gist on github:
https://gist.github.com/digitaltrails/cfd6617be9f0e5cfbdaaf951d4526aef
The downside of purging off old rpm's is that I can no longer revert to older versions via the cache. For me that's not a problem, I only want an up to date cache for seeding another desktop.
Thanks for sharing the script, Michael. Yes, I do this on purpose, updating about a dozen TW systems from it, and been lucky enough to have some storage headroom available. Cheers, Pete
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
Cheers, Pete
The rpm's in the cache are not kept by default. If it they are kept, zypper does not purge any, so many versions of each rpm may pile up. This can be useful if you need to revert to an earlier version of an rpm or wish to seed the cache of other machines. I use the cache from one machine to seed the nearly identical machine, but rather than copying over old disused rpm's I may run a home made script to do a purge first. I can post the script if anyone's interested. Cheers, Michael
On Saturday, 20 February 2021 6:23:47 ACDT Michael Hamilton wrote:
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
Cheers, Pete
The rpm's in the cache are not kept by default. If it they are kept, zypper does not purge any, so many versions of each rpm may pile up. This can be useful if you need to revert to an earlier version of an rpm or wish to seed the cache of other machines.
I use the cache from one machine to seed the nearly identical machine, but rather than copying over old disused rpm's I may run a home made script to do a purge first. I can post the script if anyone's interested.
Cheers, Michael
Have you tried apt-cacher-ng for that? It works not only for apt on debian, but also for zypper. I'm using it in a mixed environment of Debian/Raspbian and oS machines (real and virtual) and it a) means that the machines in question don't need direct internet access - only the VM running apt-cagher-ng does; and b) it saves a heap on internet bandwidth and dramatically speeds up updates for all but the first machine requesting a particular set of updates. Very simple to setup, too. Debian (and Debian-derivative) clients using apt are extremely easy to setup - zypper needs a little more work, with manual editing of the repo URL's for each repo that needs caching, but that only needs to be done once, when a repo is added (or it is deployed for the first time). Hopefully someone might find this useful. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================
On 20/02/2021 16.38, Rodney Baker wrote:
On Saturday, 20 February 2021 6:23:47 ACDT Michael Hamilton wrote:
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Have you tried apt-cacher-ng for that? It works not only for apt on debian, but also for zypper. I'm using it in a mixed environment of Debian/Raspbian and oS machines (real and virtual) and it a) means that the machines in question don't need direct internet access - only the VM running apt-cagher-ng does; and b) it saves a heap on internet bandwidth and dramatically speeds up updates for all but the first machine requesting a particular set of updates.
Very simple to setup, too. Debian (and Debian-derivative) clients using apt are extremely easy to setup - zypper needs a little more work, with manual editing of the repo URL's for each repo that needs caching, but that only needs to be done once, when a repo is added (or it is deployed for the first time).
Hopefully someone might find this useful.
What about the server? That one will need to run Debian, no? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sunday, 21 February 2021 4:29:07 ACDT Carlos E.R. wrote:
On 20/02/2021 16.38, Rodney Baker wrote:
On Saturday 20 February 2021, Hans-Peter Jansen wrote: Have you tried apt-cacher-ng for that? It works not only for apt on debian, but also for zypper. I'm using it in a mixed environment of Debian/Raspbian and oS machines (real and virtual) and it a) means that the machines in question don't need direct internet access - only the VM running apt-cagher-ng does; and b) it saves a heap on internet bandwidth and dramatically speeds up updates for all but the first machine requesting a
On Saturday, 20 February 2021 6:23:47 ACDT Michael Hamilton wrote: particular set of updates.
Very simple to setup, too. Debian (and Debian-derivative) clients using apt are extremely easy to setup - zypper needs a little more work, with manual editing of the repo URL's for each repo that needs caching, but that only needs to be done once, when a repo is added (or it is deployed for the first time).
Hopefully someone might find this useful.
What about the server? That one will need to run Debian, no?
No - at home I'm running it on Tumbleweed. If it's not in the main repo, someone has built it in an OBS repo. Can't remember exactly - I'd have to check Yast2. A package search will find it. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================
On Sunday 21 February 2021, Rodney Baker wrote:
On Saturday, 20 February 2021 6:23:47 ACDT Michael Hamilton wrote:
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
Cheers, Pete
The rpm's in the cache are not kept by default. If it they are kept, zypper does not purge any, so many versions of each rpm may pile up. This can be useful if you need to revert to an earlier version of an rpm or wish to seed the cache of other machines.
I use the cache from one machine to seed the nearly identical machine, but rather than copying over old disused rpm's I may run a home made script to do a purge first. I can post the script if anyone's interested.
Cheers, Michael
Have you tried apt-cacher-ng for that? It works not only for apt on debian, but also for zypper. I'm using it in a mixed environment of Debian/Raspbian and oS machines (real and virtual) and it a) means that the machines in question don't need direct internet access - only the VM running apt-cagher-ng does; and b) it saves a heap on internet bandwidth and dramatically speeds up updates for all but the first machine requesting a particular set of updates.
Very simple to setup, too. Debian (and Debian-derivative) clients using apt are extremely easy to setup - zypper needs a little more work, with manual editing of the repo URL's for each repo that needs caching, but that only needs to be done once, when a repo is added (or it is deployed for the first time).
Hopefully someone might find this useful.
I can see that being useful if you have a large number of machines with different software installed. I had in the past wondered about using squid to do some mirroring of repos, but the need hasn't eventuated. In my case I have two desktops and they're deliberately kept quite similar. I don't need to mirror everthing in the repos, just the 3-4GB required for those two machines. Cheers, Michael
On Sunday, 21 February 2021 7:37:33 ACDT Michael Hamilton wrote:
On Sunday 21 February 2021, Rodney Baker wrote:
On Saturday, 20 February 2021 6:23:47 ACDT Michael Hamilton wrote:
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
Cheers, Pete
The rpm's in the cache are not kept by default. If it they are kept, zypper does not purge any, so many versions of each rpm may pile up. This can be useful if you need to revert to an earlier version of an rpm or wish to seed the cache of other machines.
I use the cache from one machine to seed the nearly identical machine, but rather than copying over old disused rpm's I may run a home made script to do a purge first. I can post the script if anyone's interested.
Cheers, Michael
Have you tried apt-cacher-ng for that? It works not only for apt on debian, but also for zypper. I'm using it in a mixed environment of Debian/Raspbian and oS machines (real and virtual) and it a) means that the machines in question don't need direct internet access - only the VM running apt-cagher-ng does; and b) it saves a heap on internet bandwidth and dramatically speeds up updates for all but the first machine requesting a particular set of updates.
Very simple to setup, too. Debian (and Debian-derivative) clients using apt are extremely easy to setup - zypper needs a little more work, with manual editing of the repo URL's for each repo that needs caching, but that only needs to be done once, when a repo is added (or it is deployed for the first time).
Hopefully someone might find this useful.
I can see that being useful if you have a large number of machines with different software installed. I had in the past wondered about using squid to do some mirroring of repos, but the need hasn't eventuated.
In my case I have two desktops and they're deliberately kept quite similar. I don't need to mirror everthing in the repos, just the 3-4GB required for those two machines.
Cheers, Michael
-- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================
On Sunday, 21 February 2021 7:37:33 ACDT Michael Hamilton wrote:
On Sunday 21 February 2021, Rodney Baker wrote:
On Saturday, 20 February 2021 6:23:47 ACDT Michael Hamilton wrote:
On Saturday 20 February 2021, Hans-Peter Jansen wrote:
Hi,
4990 packages to upgrade, 3 to downgrade, 26 new, 1 to reinstall, 9 to remove. Overall download size: 3.94 GiB. Already cached: 7.18 GiB. Download only.
Fun, but why does the cached size outdo the overall size?
Cheers, Pete
The rpm's in the cache are not kept by default. If it they are kept, zypper does not purge any, so many versions of each rpm may pile up. This can be useful if you need to revert to an earlier version of an rpm or wish to seed the cache of other machines.
I use the cache from one machine to seed the nearly identical machine, but rather than copying over old disused rpm's I may run a home made script to do a purge first. I can post the script if anyone's interested.
Cheers, Michael
Have you tried apt-cacher-ng for that? It works not only for apt on debian, but also for zypper. I'm using it in a mixed environment of Debian/Raspbian and oS machines (real and virtual) and it a) means that the machines in question don't need direct internet access - only the VM running apt-cagher-ng does; and b) it saves a heap on internet bandwidth and dramatically speeds up updates for all but the first machine requesting a particular set of updates.
Very simple to setup, too. Debian (and Debian-derivative) clients using apt are extremely easy to setup - zypper needs a little more work, with manual editing of the repo URL's for each repo that needs caching, but that only needs to be done once, when a repo is added (or it is deployed for the first time).
Hopefully someone might find this useful.
I can see that being useful if you have a large number of machines with different software installed. I had in the past wondered about using squid to do some mirroring of repos, but the need hasn't eventuated.
In my case I have two desktops and they're deliberately kept quite similar. I don't need to mirror everthing in the repos, just the 3-4GB required for those two machines.
Cheers, Michael
That's exactly the point of apt-cacher-ng - it acts as a local proxy server for apt/zypper/yum, rather than a full mirror. It only grabs what's requested. If a package it not in the cache, it grabs it and caches it. The next request for that package is served from the local cache. For example, at work I have 2 TW laptops, with about 90% commonality between them. The first one that updates takes a while, because all packages are downloaded from the net. The next one gets almost everything from the local cache, so it's download takes a fraction of the time because it's happening at LAN speed. Same at home with my Raspberry Pi's - the first one that updates ensures that the cache is populated with the latest packages - the rest grab those packages from the cache, which is running on my TW desktop (because it has the most storage). It also has a way of expiring superseded packages so that the cache size doesn't grow out of control (naturally). That can be turned off if needed. Cheers, Rodney. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================
participants (5)
-
Carlos E.R. -
Hans-Peter Jansen -
Jan Engelhardt -
Michael Hamilton -
Rodney Baker