Hosting custom repository - Best way to update it?

hunter10 · 2022-12-09 17:05:29

At the moment I have a custom repository server setup so that I can control the package versions on multiple computers that will run without any user interaction.

Currently, the repository is set up by installing the latest packages from the official repositories (as of 12/06/2022) using the following:

pacman -Syw --noconfirm --cachedir /packages --dbpath /tmp/blankdb $(awk {'print $1'} /home/db-maker/package.list)
repo-add /packages/custom.db.tar.gz /packages/*.zst /packages/*.xz

Where package.list is a list of packages I need on the computers.

This currently works great - I have a custom Arch ISO build that grabs the packages from my custom repository server with

# read package list and download packages
pacman -Syw --noconfirm --cachedir $SCRIPTPATH/CustomRepo/x86_64 --dbpath /tmp/blankdb $(awk {'print $1'} $SCRIPTPATH/package.list)
# create offline db
repo-add $SCRIPTPATH/CustomRepo/x86_64/custom.db.tar.gz $SCRIPTPATH/CustomRepo/x86_64/*.zst $SCRIPTPATH/CustomRepo/x86_64/*.xz

Now, while that works great at the moment, my question is: what would the best way to upgrade the packages in the future on the server itself?

Would it be better to simply:

[ -d /packages ] && rm /packages -r
mkdir /packages

[ -d /tmp/blankdb ] && rm /tmp/blankdb -r
mkdir /tmp/blankdb

pacman -Syw --noconfirm --cachedir /packages --dbpath /tmp/blankdb $(awk {'print $1'} /home/db-maker/package.list)
repo-add /packages/custom.db.tar.gz /packages/*.zst /packages/*.xz

whenever I find that packages need to be upgraded? Or is there a better way to update the packages as required in the custom repository server?

Also, please let me know if this is the right location to post this on the forum.

Thanks!

Last edited by hunter10 (2022-12-09 17:05:57)

cfr · 2022-12-09 21:38:11

Why do you want a custom repo rather than sharing the package cache exactly? If you're only using packages from the official repositories, that seems a cumbersome way to do it?

How do you plan to handle updates which require user intervention or produce .pacnew or .pacsave files?

Last edited by cfr (2022-12-09 21:39:31)

hunter10 · 2022-12-09 22:31:12

Sorry, I did mean I'm only hosting the package cache itself. Essentially, all packages that are in the /packages/ folder are just hosted on the server with a custom.db file created with repo-add.

You make an interesting point on the .pacnew and .pacsave files - unfortunately I am simply taking over for what a former coworker has set up previously and it sounds like full automation using an Arch Linux installation may be difficult.

cfr · 2022-12-09 23:28:05

Then I don't see you need a repo (or repo-add) at all. See https://wiki.archlinux.org/title/Pacman … cman_cache for ways to share the cache. I would expect that to be rather easier to maintain. A custom repo would be needed if you wanted to include pre-compiled software *not* in the official repos. If that's not the case, I don't see the point.

You shouldn't try to automate updates on Arch, no. If the machines are perfect replicas, you could probably update one and automate the others.

Note that 'control package versions' doesn't make much sense on Arch either. You can't update some packages and not others unless you want to break your system. Partial updates are not supported.

You can, obviously, not update at any given time, but, if you don't update reasonably frequently, you risk running into difficulties.

Last edited by cfr (2022-12-09 23:28:37)

Scimmia · 2022-12-10 02:17:49

You're missing the point. They're trying to freeze the system at a certain point by running their own repos.

cfr · 2022-12-10 03:35:50

Scimmia wrote:

You're missing the point. They're trying to freeze the system at a certain point by running their own repos.

But why can't you freeze it by using a shared cache? If you don't update the machine responsible for the cache, isn't the effect the same? You're controlling the updates on the other machines, so they just don't update.

Or is the idea that automated updates will run on the other machines regardless of whether you want them updated or not, so only by replacing the repo can you prevent them getting new versions you don't want? In that case, I can see you'd need a custom repo.

hunter10 · 2022-12-12 17:54:46

I did forget to mention - I do have a custom piece of software that is running on these machines that is packaged and added to the repository, so just sharing the cache would not work in this case.

Lone_Wolf · 2022-12-13 11:16:40

I do have a custom piece of software that is running on these machines that is packaged

When you install that software on the machine where the cache resides, pacman will place it in the cache folder.
Incase you don't want to install it on that machine, you can manually copy the *.pkg.tar.zst (+ sig-file if it exists) to the cache folder.

That way the shared cache will contain your custom software.

Arch Linux

#1 2022-12-09 17:05:29

Hosting custom repository - Best way to update it?

#2 2022-12-09 21:38:11

Re: Hosting custom repository - Best way to update it?

#3 2022-12-09 22:31:12

Re: Hosting custom repository - Best way to update it?

#4 2022-12-09 23:28:05

Re: Hosting custom repository - Best way to update it?

#5 2022-12-10 02:17:49

Re: Hosting custom repository - Best way to update it?

#6 2022-12-10 03:35:50

Re: Hosting custom repository - Best way to update it?

#7 2022-12-12 17:54:46

Re: Hosting custom repository - Best way to update it?

#8 2022-12-13 11:16:40

Re: Hosting custom repository - Best way to update it?

Board footer