[Solved] DBPath for "local" and "sync" directories for pacman

stri · 2020-10-27 14:06:14

I have an Arch host system and want to install Arch guests in multiple directories, for later use with systemd-nspawn, qemu, bare metal etc.

I'd like to keep the "sync" db on the host, but the DBPaths to "local" on the guests, to avoid redundant "sync" db updates for each guest. Only the "local" dbs on the guests need to differ.

Using systemd-nspawn, would it be safe to

--bind

the guest's "sync" directory to the host's?

Is there a better way to solve this?

There was a similar post a couple of years ago, although their motivation may have been different:

https://bbs.archlinux.org/viewtopic.php?id=227247

Thanks for your help!!

Last edited by stri (2020-10-28 15:56:48)

Lone_Wolf · 2020-10-28 15:05:23

Sounds like you should setup a shared pacman cache.

https://wiki.archlinux.org/index.php/Pa … cman_cache

an alternative approach is https://wiki.archlinux.org/index.php/Pacserve

stri · 2020-10-28 15:44:16

Thanks for your help!

I thought about this too, but given that all guests are on my local machine, I was hoping there was a solution without fileserver.

Hence the idea to separate the "host" and "sync" paths.

If pacman doesn't allow it, I wonder if I could have a shared directory /shared and then point each guests DBpath to /shared/guestXX, like

/shared/guest01
  /local
  /sync -> /shared/common/sync
/shared/guest02
  /local
  /sync -> /shared/common/sync
...
/shared/common/sync

I try it tomorrow, if it doesn't work I use a file server.

[EDIT] also, I think using the file server one wouldn't have to worry about concurrency. I think my approach would break if two guests would update "sync" simultaneaously.

Thanks again!

Last edited by stri (2020-10-28 15:53:56)

Trilby · 2020-10-28 16:01:23

Why do you want to share sync databases? They are trivially small (compared to everything else pacman downloads), and sharing sync databases could easily get you into a partial upgrade scenario (as any update on any system would result in the same as running `pamcan -Sy` on all the other machines).

Just share the package cache. This can be done in any number of ways (just not symlinks) as described in the first link Lone_Wolf provided - there is no need for a file server. Mounting, bind mounting, or hardlinks all should be possible options. In fact, as you say these are systemd-nspawn containers, you should have noticed the entry on that wiki page specifically for this use case:
https://wiki.archlinux.org/index.php/Sy … filesystem

stri · 2020-10-28 16:22:20

I already share the cache, and I don't use a file server. But this is not my problem.

My problem is the syncing of the database, it sometimes takes longer than to install the actual packages from the cache.

sharing sync databases could easily get you into a partial upgrade scenario (as any update on any system would result in the same as running `pamcan -Sy` on all the other machines

Thanks, good point! So that's not a good solution.

How about symlinking the *.db files into the cache and using

 
Server = file:///path/to/cache

in the pacman.conf of the guest.

But what would happen if the package is not in the cache?

[EDIT] hmm, if it's neither cached nor on the mirrors (due to oudated *.db) I could simply update the host and retry. I'll try and see if it causes trouble.

Last edited by stri (2020-10-28 17:17:05)

eschwartz · 2020-10-28 19:29:14

You could set your /etc/pacman.d/mirrorlist to check a Server that is actually a bind mount from the host's DBPath. You might need to set a fallback server to actually download packages that are not yet in the cache from a real mirror.

stri · 2020-10-29 09:56:55

You could set your /etc/pacman.d/mirrorlist to check a Server that is actually a bind mount from the host's DBPath. You might need to set a fallback server to actually download packages that are not yet in the cache from a real mirror.

Thanks so much for the advice, that's gold!

I hadn't realized that I can use a file URI in the mirrorlist! That's much better than to define the repository as a file URI, because now the fallback download mechanism works! I think this will make my life much easier. I just have to take care not to let the host *.db go stale, so the files missing in the cache still exist in the mirrors.

eschwartz · 2020-10-30 01:34:41

The mirrorlist can have anything that would be valid in pacman.conf (it is literally "include"d) and the "Server =" directive is doing all the work. The mirrorlist is just a common convention for one file containing Server directives used in multiple repo sections.

The "Server =" directive accepts any form of URI which the download agent can interpret. Usually this is the libcurl internal downloader. libcurl supports, among other things, file:// which is quite neat.

Arch Linux

#1 2020-10-27 14:06:14

[Solved] DBPath for "local" and "sync" directories for pacman

#2 2020-10-28 15:05:23

Re: [Solved] DBPath for "local" and "sync" directories for pacman

#3 2020-10-28 15:44:16

Re: [Solved] DBPath for "local" and "sync" directories for pacman

#4 2020-10-28 16:01:23

Re: [Solved] DBPath for "local" and "sync" directories for pacman

#5 2020-10-28 16:22:20

Re: [Solved] DBPath for "local" and "sync" directories for pacman

#6 2020-10-28 19:29:14

Re: [Solved] DBPath for "local" and "sync" directories for pacman

#7 2020-10-29 09:56:55

Re: [Solved] DBPath for "local" and "sync" directories for pacman

#8 2020-10-30 01:34:41

Re: [Solved] DBPath for "local" and "sync" directories for pacman

Board footer