Comment 5 for bug 335596

There are two key problems here. The first is that trying to remove even a single package, which we do when testing whether we should not bother to copy its files if we're just going to remove the package anyway, is relatively slow (well, on the order of a quarter to half a second for me, but it adds up when you're talking about hundreds of packages). The second is that, if a package can't be removed because it's needed by a language pack that's staying installed, then having to repeatedly try to remove it and then put it back each time we look at one of its dependencies is *really* slow. This second problem is particularly noticeable when you ask for lots of language packs to stay installed.

I've decided to address the second problem first, and have applied this change to ubiquity:

  * Expand dependencies of packages we know we want to keep (language packs,
    etc.) before calculating which packages to blacklist from file copying
    or to remove. This is more correct in the presence of Recommends of
    language packs, and furthermore saves considerable time when
    blacklisting. My test results for various language pack sets:
    - en: 4:00 -> 3:30
    - de+en+es+fr+ja+ko+nb+nds+nl+nn+si+sk+sv: 5:30 -> 2:50
    - all: 14:37 -> 0:10 (!)
    This doesn't quite solve LP #335596 because testing a large number of
    packages for removal when there genuinely are lots of packages to remove
    is still quite slow, but it very significantly improves the worst cases.

Is it acceptable to you to continue installing all language packs? If so, I think this should clear this bug off the oem-priority list; 10 seconds is easily going to be less than the time saved by not having to copy all those files. If that isn't acceptable, then we'll need to do some more work.