tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: creating unique urls for binary packages




> On May 18, 2017, at 3:12 AM, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
> 
> * On 2017-05-18 at 07:53 BST, Jonathan Perkin wrote:
> 
>> * On 2017-05-18 at 06:24 BST, matthew sporleder wrote:
>> 
>>> A few days ago we ran into a situation where some packages were
>>> rebuilt but not given new names, causing pkgin and friends to be upset
>>> about checksums of files not matching pkg_summary because
>>> cdn.netbsd.org had the packages cached from the previous build.
>>> 
>>> There are a few ways to resolve this, but the easiest one is to have
>>> the client (pkgin) append a unique identifier (like the build date) to
>>> the package's url:
>>> bash-2.05.2.13.tgz?BUILD_DATE=2017-01-07_23:23:31_+0000
>>> 
>>> when it fetched that package.
>>> 
>>> Thoughts?
>> 
>> This seems like a bug in the CDN?  pkgin itself should handle rebuilt
>> packages ok, as long as you are running a version with this commit:
>> 
>>  https://github.com/NetBSDfr/pkgin/commit/f21d2ec9
>> 
>> Are you not enabling ETags or something?
> 

A hit is a hit is a hit. We use cache control max-age not must-revalidate or similar. 

Revalidating each time is an option but is slower than just allowing a pure edge hit. Also since netbsd has been trying to dogfood bozo I am not super confident if-modified-since is going to do anything. I don't think bozohttp has etags.  Switching to apache is not a big deal to solve some of these if it comes to it. 


The query param idea is just one option. We can also use a header + Vary or use a smart purging strategy on build, but a URL param is just super easy. 

> I forgot to mention, one of the main issues around providing a binary
> package repository is ensuring that updates to the repo are atomic, or
> at least as tight as possible, as all of the packages need to be in
> sync with pkg_summary and its checksums of them all.
> 
> To help fix that in our environment (we rebuild more than most so have
> run into this quite a bit in the past) I have this pbulk patch:
> 
>  https://github.com/joyent/pkgsrc/commit/7c32dd9

Good idea. I am not that involved with the bulk build origin part though. 

> 
> and I have a similar mechanism in the script which is used to mirror
> packages across our pkgsrc.joyent.com mirrors.
> 
> Since making those changes and the pkgin one above we've had much
> fewer complaints about bad checksums - I don't remember the last time
> we had one.

Are you using must-revalidate or something else?


Home | Main Index | Thread Index | Old Index