# meta.txz and packagesite.txz reduce number of times downloaded



## perkypork (Mar 10, 2016)

Hi Everyone,

We are trying to increase the speed of our jail creation and one thing that slows us down is the number of times meta.txz and packagesite.txz is updated. Is there a way to grab a cache of the files or set them to not update for a period of time or any other way we might be able to reduce the number of times these files are downloaded and processed?


----------



## SirDice (Mar 10, 2016)

You could try and set REPO_AUTOUPDATE. But that does mean you'll have to run pkg-update(8) for it to update. Otherwise it won't pick up on changes in the repository. 

From pkg.conf(5):

```
REPO_AUTOUPDATE: boolean
                      When true, automatically check for and download updates
                      to /var/db/pkg/repo.sqlite when running one of: pkg
                      fetch, pkg install, pkg rquery, pkg search, pkg upgrade,
                      or pkg version -R.  Default: YES.
```


----------



## marino (Mar 10, 2016)

see the man pages for pkg. specifically see the "-U" aka " --no-repo-update" switch.
If that switch is present, you are tell pkg explicitly not to check (and implicitly that you already know it's up to date)

you could have a cron just update every 24 hours as a parallel process.


----------



## perkypork (Mar 15, 2016)

Thank you very much for your replies. I think that both options need to be set inside the jails and not from the host, I have yet to find a way to deal with this from the host. To solve having to download packages for each jail, we mount the pkg cache folder from the host inside the jails which makes things much faster for subsequent installs of packages. Have yet to find out how we do this for Jails.


----------



## perkypork (Mar 15, 2016)

We ended up solving this issue by setting REPO_AUTOUPDATE = false; in the jail and then copying /var/db/pkg/repo.sqlite from the host into the jail just before a package was installed. Reduced jail creation time significantly.


----------

