contents-generation could be 2x faster by not regenerating Packages/Sources
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
apt (Debian) |
New
|
Unknown
|
|||
apt (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
10:25 <cjwatson> Why does contents-generation generate its own dists/ rather than copying the most recent published version, anyway? I get why it has a separate dists/, but I don't really see why it has to go to the effort of generating its own.
10:28 <cjwatson> Oh, maybe it's just hard to get apt-ftparchive not to do so.
10:29 <wgrant> Because I hate apt-ftparchive.
10:30 <wgrant> But yeah, it's probably difficult to tell it otherwise.
10:31 <wgrant> Or was in 2006.
10:32 <cjwatson> It takes it 100+ minutes to generate all the Packages and Sources again, so avoiding that would be a nice improvement.
10:33 <cjwatson> Then Contents takes 90 minutes.
10:33 * cjwatson files a bug.
10:33 <wgrant> Oh
10:33 <wgrant> It doesn't preserve?
10:34 <cjwatson> Not so you'd notice.
From a brief foray into the code, I think it may indeed still be rather difficult to tell 'apt-ftparchive generate' not to update Packages/Sources every time. Worst case, perhaps we can fall back to using 'apt-ftparchive contents' manually.
Related branches
Changed in launchpad: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: packages |
tags: | added: soyuz-publish |
Changed in apt (Ubuntu): | |
importance: | Undecided → Medium |
Changed in apt (Debian): | |
status: | Unknown → New |
Something like http:// paste.ubuntu. com/1050714/ may work, I add a apt task.