Re: [Apt-proxy-users] endless recycling

[Micha <ear...@gm...>]

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 :)