dists.new kludge in cron.daily is suboptimal
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
As far as I can tell from rsync logs, cron.daily apparently does something like 'cp -a dists dists.new' and then generates (via apt-ftparchive) indices files in that tree. This is suboptimal for a couple of reasons:
(1) You're performing a lot of expensive and unnecessary IO - a) the dists tree is quite large due to the presence of '*installer-*' directories for the various suites, b) apt-ftparchive doesn't need any of the files in dists/, all it needs is the directory structure.
(2) You're making the visible archive inconsistent. If someone performs an out-of-band rsync from syncproxy or ports, it's possible for them to end up getting a copy of dists.new which is expensive and ugly.
If you must generate to a new dists tree, I'd suggest it be done to a) a dists/ tree _outside_ of the ubuntu-archive/ root so that out-of-band rsyncs can't see it, and b) you either copy just the directories from dists/ or just create needed directories on the fly (see 'dak init-dirs' for an example of code to do this based on an apt.conf file).
Changed in soyuz: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: soyuz-publish |
This is now very slightly less suboptimal; most objections above are still there, but we now use rsync instead of cp, which seems to have taken most of the minutes out of the process.