Downloaded patches aren't cached

[MikeMcQuaid]

I tried to install a Homebrew package on a plane the other day to find to my disappointment that although the sources are cached the patches are not. Any good reason for this or can I implement a fix?

[adamv]

Have to make sure that the filenames for the patches don't blam on top of each other, ie, they have to be unique like the cached tarballs are.

[MikeMcQuaid]

Aye. Could do either $SHA1.patch, $SHA1.diff, $FORMULA-$SHA1.patch, $FORMULA--$VERSION-$SHA1.patch or something similar. Let me know which you are most keen on and I'll implement it.

[adamv]

Personally I would do it with subfolders in the Cache, name the folder like the tarball, so cross-version and cross-brew patches wouldn't clash; but I think Max wasn't keen on subfolders or something. I don't really remember.

Also: the "download the patches" code ought to be refactored somehow.

[MikeMcQuaid]

SHA1 should be unique enough, SHA1 plus formula definitely will be. Tagging for mxcl.

[adamv]

The existence of DATA patches makes this difficult; we don't want to cache those ones.

[mxcl]

I think overall it was more hassle than it was worth. Practically how often do you reinstall formula on a plane or in a tunnel? Because this only applies if you think that the formula in question should be cached, because you installed it once already.

Basically I would cache nothing (caching is evil, remember?) if we could get away with it. But considering formula may fail to install, expecting the user to download big tarballs everytime when they are trying to fix something is unreasonable.

Patches are small. Caching is not required.

[MikeMcQuaid]

I actually do this moderately often (once a month or so) because I fly so damned often. Bottling support has made this less painful however.

[mxcl]

Yes, well my point is, you are not a normal user by any stretch of the imagination.

While I can see the point, caching should be avoided at all costs IMO. I can just imagine the bug where the wrong security patch is applied and the president of Pakistan dies as a result, ushering in world war three.

Don’t make me responsible for 6 billion deaths Mike. Think of the children.

[adamv]

Closing to avoid killing the president of Pakistan. Though on a related note consider having checksums per patch.

[mohrr]

I have an additional case where this would be helpful. I have Macs on a network that isn't connected to the internet (as opposed to those who are just temporarily disconnected). I had hoped bringing the cache folder from my laptop into this network would mean I could use Homebrew. Because of the issues mentioned above I'd rather not try to hack it on my own.

[mxcl]

As Adam said, we can start doing this as long as we enforce checksums on patches. Not sure why I didn't think of that, but it does indeed avoid caching bugs, well, the bad ones at least.

So, someone could add this as long as the patches are only cached if there is a checksum present. Then we can start getting people to add checksums for patches that are downloaded from now on.

[xxxajk]

And... Two years later, and caching of patches still has not happened. Here is an extra idea. Instead of worrying about the sum on the patch, If it does not exist, save the patch in the cache in urlencoded form. That way you match on the actual url within the cache. patches normally don't get an update anyway, thus the url should change for it. Worse case, the user can clean the cache ;-)

[MikeMcQuaid]

@xxxajk Pull requests welcome.

[xxxajk]

@MikeMcQuaid I am still learning ruby. I am also using it on Linux (the linuxbrew). Will I be able to do it from that, or would I need to fork both? Would the project be interested in supporting both platforms?

[MikeMcQuaid]

You'll need to fork Homebrew if you want it included there. You should also look at #21648.