Package Sack and Depsolving Notes

One Yum Object

Why do we only have one yum object? Because we don't want to initiate another yum object. It would need to have the same install_root and cache directory to prevent depsolving, downloading and possibly installing from happening twice. Having multiple yum objects would require us to have multiple install_roots (because yum locks the transactions) and would thus also have separate cache directories, which hold the repository information as well as the downloaded packages.

So: One Yum Object, to rule them all!

Populating the Package Sack

There's several steps involved in populating the package sack. I'll list them in order:

1. Include any packages selected from the optional package manifest in a kickstart file
2. Include any packages selected in the package selection dialog
3. Add overall required packages
   
4. For installation media, add the appropriate required packages
5. For live media, add the appropriate required packages

Each and every one of these steps depend on whatever options are set. Step 1 for example may just be an empty list of packages if the user choose not to use the kickstart package manifest. Step 2 then doesn't require you to select any package at all. So when arriving at step 3, your package sack may still not be populated at all. Luckily the packages added in step 3 are required under any circumstance (regardless of whether you want installation media or live media), so we can add those packages anyway.

So after step 3 we have a minimally populated package sack, which we obviously want to depsolve because including dependencies we can consider it the minimal package sack with selected and required packages. From there (step 4 and/or 5), we can build package sacks that include required packages for either installation media or live media.

After step 3

After step 3 all we want is in 'self.cfg.yumobj.tsInfo.pkgdict':

self.cfg.yumobj.tsInfo.pkgdict: {
(u'fedora-release', u'noarch', u'0', u'6', u'4'): [<yum.transactioninfo.TransactionMember instance at 0xa7b534c>],
(u'libxml2', u'i386', u'0', u'2.6.28', u'1.fc6'): [<yum.transactioninfo.TransactionMember instance at 0xa7b0f6c>],
(u'yum-metadata-parser', u'i386', u'0', u'1.0.3', u'1.fc6'): [<yum.transactioninfo.TransactionMember instance at 0xa765b8c>],
(u'filesystem', u'i386', u'0', u'2.4.0', u'1'): [<yum.transactioninfo.TransactionMember instance at 0xa7b2b0c>],
(u'libsysfs', u'i386', u'0', u'2.0.0', u'6'): [<yum.transactioninfo.TransactionMember instance at 0xa7aed8c>],
(u'audit-libs-python', u'i386', u'0', u'1.4.2', u'5.fc6'): [<yum.transactioninfo.TransactionMember instance at 0xa7b7b4c>],

[...]

To this set of packages, depending on what we are going to do, we would want to:

• add installation media required packages, if we are going to do installation media
• add live media required packages, if we are going to do live media

With this 'pre-populated' package sack as a basis, being depsolved and all, we can easily -well "easily"- rebuild our transaction information with the data we store.