From: Micha <ear...@gm...> - 2005-02-03 03:34:19
|
Chris Halls <ha...@de...>: > The mtime is not really all that useful. There are lots of packages that may > be quite old, e.g. all of Woody, where it is more important to know whether > clients are actively downloading the package rather than the time since it > was created. I must admit i don't really understand that feature. If a package wasn't requested for a month that doesn't mean it couln't happen just today. And with huge amount of disk space, my decision would be to have woody, or have not. I wouldn't delete olf files automatically. And then, usually the reason for woody is stability and security. So i still would like to have the last security fix. There are quite a lot of packages that ap had to refresh, anyway. But i assume that you simply kmow of users who want it that way, and for good reasons. > Or perhaps you were thinking of setting the mtime to the time > when ap wrote it, instead of the timestamp of the file itself? yes, that's what i meant with 'touching' it. > My guess would be a problem with the database permissions bugs that took > several attempts to fix. The uploads were only to unstable, and life in > unstable is not guaranteed to be perfect I'm afraid. Well, in two weeks i'll see if it happens with testing too. > when large numbers of files are copied into the cache. However, since the > recycling is just taking a note of the time the file entered the cache, it > doesn't matter if it takes a while before apt-proxy notices. The database > entry is not needed when serving the file, only when doing cache cleaning. You mean it's supposed to run in the background ? Then why got Jonathan a 'service unavailable' (or whatever, sorry, original posting's already gone) ? btw. your first reply wasn't right quoted, i hope it's clear that the problem occured on Jonathans machine, not mine. > (There are wishlist bugs open asking for download resume, which makes a lot of > sense for large packages) oh well, i second that ! :) I often download kerneltrees. > > Are you proposing to compare a checksum every time a file is served? > > I think that's a lot of work for something that just isn't going to > > happen. Well, i can't imagine it's that much work. Other package software does, too. I think it also could be an additional security measurement. But as i said, i'm no programmer. > I don't want to have to involve the sysadmin. They could be not available Yes, that's a good point generally. But....think of the jobs :) |