On 23 Sep 2003, at 4:03 pm, [EMAIL PROTECTED] wrote:
Could you explain what concurrency issues you anticipate, please..?
Simply that two (or more) clients would try to download and _store_ the
same file at the same time... could also
be that one or more client believes it is already downloaded because the
first bytes were just downloaded by another client.
The clients will not download a file if only part exists - the md5sum of the downloaded file will not be valid & the emerge will fail.
Both could be managed by a midnight cron job, for instance.
Let me clarify that:
I think that in this situation it's advisable to ensure that no two machines `emerge sync` at the same time... also need to `emerge -fu world` ...however this... could be managed by a midnight cron job, for instance.
I feel unhappy with automatic system updates. Should etc-update be executed
automatically after the emerge or not? Should every operator check his/her
computer every morning to see if en etc-update gives something to do?
The `emerge --update` is done separately - no-one sensible would advise system updates without manual intervention. However if all the files are stored on one machine & exported over NFS, then it is expedient to have that machine do the fetching of all files. A cron job to `emerge sync && emerge -fud world` does NO installation or upgrading of any systems - it only updates the local portage database & fetches the updates you require. It would, I would think, be quite easy to unshare the NFS export before getting the files, and reshare it afterwards, as part of the cron job. If this is done at 4am, then it is likely to cause little interruption to service in most environments.
A script is, however, given that (with some discretion, I think) deletes files in this directory as you require; this script could of course also be cron'd.
That's great, except that it has to be _procedurally_ syncronized again. We
wouldn't want to run this script before the emerge had finished, would we?
I don't think this should be a problem if it only deletes distfiles which are over (say) a month old. But I haven't examined that script; I think it would also be possible to go something involving `qpkg -I -v` and a less-than statement.
I don't quite see what your problem is with a 'procedural" solution: you can use cron to only get files on odd days of the month, and only delete old ones (I think) on even days. The only intervention necessary is to install them, which is as it should be.
IMHO, any deletion of ../distfiles/* should happen in the end of an emerge
sequence. But again, that's just an opinion.
Well, I think you should be able to write a wrapper script called `myemerge` which simply calls emerge with the same parameters as those with which it was itself invoked, then empties distfiles for you.
I hope you forgive me expressing my opinion - I think you're making a problem out of nothing with this. I see quite simple solutions using bash scripting which will get you what you want. Whilst it might seem a little kludgy to have to do things yourself, and that it might be nice to have the facilities you describe built into Portage when it eventually gets completely rewritten, I think that scripting solutions are quite adequate in the circumstances.
Stroller.
-- [EMAIL PROTECTED] mailing list
