Re: [Question] Hosting my own private mirror with only the packages I need

[Duncaen <Duncaen@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/34205#issuecomment-975990476

Comment:
TLDR: Just host a caching http proxy, here is an nginx example: https://gist.github.com/Duncaen/645f119544a65ad0fd32e0e0400e22a3.

>  So if I have my own custom repo hosted on my network and still be able to install packages from the main void repo. Another thing that isn't really documented if multiple repos is a thing is if each mirror has to host ALL of the packages in the main void repo or even if they just require the dependancies of the custom packages(like if I have a custom version of glew do I need to host my own version of glu or can glu be pulled from the main mirror to compile glew). I was hoping to be able to remove all the packages I'm not using to reduce the storage requirement of the mirror basically.

There is no such thing as a mirror in xbps, there are repositories and you can as many as you want.
But the first repository containing a package name is choosen to provide that package.
So adding your own repository prior to the official repo will choose the packages you have in your repo from your repo and the other packages from the official repo.

A mirror is a mirror, not half or incomplete, if the repository index advertises a package name then the package will be downloaded from that mirror.

Using a caching http proxy will cache packages you request so subsequent downloads of the package will come from the cache, by configuring that cache you can limit the cache size and how long a package will be retained, no additional administration or anything required, you don't have to maintain a list of packages to mirror or cleanup old packages.
It just like a normal repository mirror, things that are not in the cache will be downloaded and passed through to the client and then retained in the cache for subsequent requests.