On 02/09/2011 04:43 PM, James Antill wrote:
On Wed, 2011-02-09 at 14:53 +0200, Panu Matilainen wrote:
Initialize + populate the transaction set to be used for the test-run
before calling rpm_check_debug to let them use the same set, avoiding
one round of the fairly expensive re-population of the entire transaction.
---
cli.py | 12 ++++++------
yum/__init__.py | 18 ++++++------------
2 files changed, 12 insertions(+), 18 deletions(-)
[...]
- # clean out the ts b/c we have to give it new paths to the rpms
- del self.ts
Assuming you tested running transactions with/without --installroot and
with/without local rpms ... ACK.
Yes I've done basic testing with those.
As for the above comment about adding new paths... it seems highly
peculiar if you think about it: we stuff pile of packages into a
transcation, run dependency sanity-check on it, throw it away and then
populate it with "different paths". What the heck was it that we just
sanity-checked then? :) ts.check() is supposed to be done with the very
same transaction instance that gets executed (test-run or otherwise),
anything else just doesn't make sense.
Digging around a bit: the comment appears to originate from commit
674428ba0f0f125972287b0f0b47f57e975c6070 (which then got more or less
copy-pasted into yum/__init__.py later on), which is in the days when
yum was downloading headers for depsolving, so probably it refers to
that: the header files lived in different path than the final downloaded
package (iirc). Even in the day, from rpm POV the repopulation for
"different paths" was unnecessary: rpm transaction doesn't know diddly
about paths, it only knows about file descriptors passed to it. What
can, and probably did, make the difference here is the "key data" passed
to ts.addInstall(), which is used in the callback to locate the package
file. It doesn't have to contain an actual path (as long as the callback
can find the file by other means), but probably did, hence the comment.
So it /was/ valid comment back in the day in the place where it
originated, in the surrounding implementation. These days, the comment
is simply long long way from home, lost and lonely :)
And with that, I'll end this mornings software archeology cryptic
musings session...
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel
