Share downloaded packages among VMs?

I’m very often at locations with bad internet connections.
I run manjaro as host system, and two manjaro VM’s.

Is there a way these three machines can share the update downloads?
I’m thinking maybe if I share a folder on the host machine with the VM’s, the VM’s does only need to download packages that is not present on the host when they do updates.
If so, which folder should be shared? Should it be shared a read only? Is there some config that should be done to make sure the machines doesn’t disturb each other?

Alternativly, I could copy a folder from one machine to the other.

My goal is to avoid spending much time waiting for updates to download. I’m currently looking forward to 2 hours of downloads for one of the vm’s. And I know 99% of the packages was downloaded by the other vm a couple of days ago.

/var/cache/pacman/pkg

I have done the same - but just for my VM’s
because the host machine is not Manjaro (or Arch) - the host is currently Mint.

Thank you
Could the folder be shared or does it need to be copied?

I created a second virtual hard drive, moved the content of /var/cache/pacman/pkg to there
and added it to each VM’s /etc/fstab
(and, of course, to each VM configuration as a second drive …so the VM can see it)

You could use the /var/cache/pacman/pkg of your host machine and share and mount that directory.
I’m not very familiar with the methods to do that, to share a host folder with a VM.
It’s certainly possible though.

example will follow - need to boot up one of the VM’s

the example
cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=704bc629-68c8-4d64-945a-7d808b904809 /              ext4    defaults,noatime 0 1
UUID=98195df8-0bc0-4b79-abb7-8ea21d40999f /var/cache/pacman/pkg ext4 defaults 0 0

the second disk is shared among all the VM’s
(Gnome, Plasma, Xfce4) - same /etc/fstab entry

What I was worried about is if the content of that folder is changed by another machine, will it cause trouble? I.e if there is a database knowing what should be there, and when another machine changes whats in the folder, there is a missmatch with the database

Hi @marli,

Look at pacserve:

https://wiki.archlinux.org/title/Pacserve

And there is a database - and you should definately use some kind of local mirror - that be on the host machine - or a removable harddisk.

The initial mirror creating process may take some time - but then it is only a matter of syncing the packageset e.g. monthly or what ever fits your schedule.

Will the mirror stick to the package I need (for my installation), or will it fill up with all packages in the repo?

With a mirror you don’t get to choose. But you can limit to any given branch.

The package manager uses a set metadata - your set of packages must match the metadata otherwise it won’t work.

So yes - you will get all packages from the branch - just see the linked topic.

In any case you still need one system to rule them all - you cannot randomly choose - that won’t work - if you should accidently make it work - the chance of getting weird issues will be ever present.

You can use something like pacserve mentioned above

What will be the problem if I just copy from one to another, like @Nachlese suggested?

The mismatched meta data

The question has been asked before - more than once - and possible solutions has been discussed - please use the search function.

any way to tell packman to look for the files it wants to download in another (local disk or network) location before downloading from the internet?

you clearly don’t read the answers - you keep asking the same question over and over - read the pacserve link provided above.

That is what pacserve does …

Optionaly, tell pacman to look if the file already is in the cache before downloading, the just run checksum and skip to download if it’s ok?

oh. I thought pacserve was a way to set up mirror

I disagree with @linux-aarhus
In /var/cache/pacman/pkg are just packages and their signatures.

Where could any conflict arise from I don’t see.

Not even with using different branches on the different Manjaro VM’s.

It’s just more packages then - different versions of them.
Still better than maintaining a separate /var/cache/pacman/pkg for each instance.

Then you don’t understand how pacman handles dependencies.

You can install a single package uing pacman -U pkgname-version.pkg.tar.zst.

But in case of dependency - you get a random version - if it is available on the system - that may not be the right one - that info is stored elsewhere - /var/lib/pacman/sync - it may work and it may not - if it does not work and you don’t know how the package manager handles these things - then you are blaming the distribution - for screwing up your system.

The scenario is not an update scenario but a break my system scenario.

System sync comes in bundles - with meta information - the database files - it is your system - you do what you want - but don’t complain when it breaks.

And the orignal topic is about a system sync - not about a single package installation.

You cannot run a pacman -Syu on the content of /var/cache/pacman/pkg - or copy the content to another machine and expect it to be able to update - metadata will be wrong.

In that case you do provide the full name - and thus you do not get a random package, but the one with the name you provided.

/var/cache/pacman/pkg is just a package cache - no?

If what is wanted or needed is not in there - it needs to be fetched.
Why would pacman just choose some random similarly named package? …

I did just that - to avoid having to download most of the packages three times instead of just once.
It worked as intended.

You can use repoctl to create a unified repo - copy all files from /var/cache/pacman/pkg on the three different systems to a shared folder.

Read about repoctl AUR (en) - repoctl upstream GitHub - cassava/repoctl: Make it easy to manage your local Arch Linux repository.

Using pacserve is likely to be easier in the long run.