<gengor> zmedico: I know this will sound a bit silly and I understand if the answer is 'no' but thought I'd throw this out there. A cached binhost 'Packages' file is stored @ /var/cache/edb/binhost/ and there is a TIMESTAMP in that file. We ran into an issue where people were manually stitching new Packages into it and not updating the TIMESTAMP. So the clients thought they had the latest Packages file and couldn't see the new packages. <gengor> Total user fail, I know. <gengor> but I was just wondering if there's any interest in making it a bit more robust against that by doing something like checksumming the Packages file <gengor> instead of relying on TIMESTAMP alone <zmedico> gengor: why would users want to modify Packages files in /var/cache/edb/binhost/? <zmedico> seems like an odd thing to do <gengor> zmedico: they stitched in new packages in the Packages file on the binhost, not the client. <gengor> zmedico: but the client already had a cached copy of hte Packages file @ /var/cache/edb/binhost/ <zmedico> oh, I see <gengor> and so didn't see the new packages because they didn't update TIMESTAMP when they edited the Packages file manaully <gengor> total user fail. but I see an opportunity to make portage more robust against that. <gengor> I'll gladly file a bug.. I just wanted to know if it would be a straight 'no' <zmedico> the thing is, you can't embed the checksum in the file itself <zmedico> it's a catch-22 <gengor> zmedico: right, but does the client pull down the new Packages file and compare it to the cached copy? <zmedico> no, it only compares the first few lines (without downloading the whole thing) <gengor> How does it get/know what the TIMESTAMP is in the Packages file in the binhost? <gengor> ahh <gengor> makes sense <zmedico> I don't think it's too much to ask to bump the TIMESTAMP when it's modified <zmedico> maybe we just need to document that better <gengor> I agree totally <gengor> they just didn't know/didn't notice <gengor> thanks for all the input zmedico. most helpful as usual :) <zmedico> you're welcome :) <gengor> zmedico: <gengor> <danp> gengor: makes sense. what about using the "modification time" of the file, whether it's gotten from local file access, HTTP header, FTP info, etc. <gengor> and if any ! match then re-download+cache? <gengor> zmedico: if that idea sounds feasible and palatable to you I'll gladly file a bug. <zmedico> gengor: yeah, that's feasible. go ahead and file a bug please if you like. <gengor> zmedico: will do. thanks :)
I don't think we really need to support user editing of the cache file, so I'm resolving this as WONTFIX. On a related note, since portage-2.1.11.10, we have support for If-Modified-Since http headers: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e06cb6d66db37ac7ab77acf65038b1f770c13c96
