Restructure system affection detection.

Store "vulnerable" and "upgrade" packages in a table, and use that
data to determine which packages cannot be upgraded, and which
packages actually cause upgrades

svn path=/trunk/gentoolkit/; revision=648

http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=b6a2a23926d54ccfa9a1ce331c1bc97dbe2c73d1
Do not inject GLSAs into the checkfile when fixing them

There is no reason applied GLSAs must be stored in a checkfile. In the
current glsa-check GUI this will make it impossible to determine whether
the system is still affected by the GLSA (e.g. by re-emerging, or when a
GLSA is changed afterwards).

The current place for the checkfile (/var/cache) is not persistent per
FHS, meaning that people might clean out the contents of their injected
GLSAs. Since glsa.py is moving to portage anyway, we can use
/var/lib/portage as a place to store the injected GLSAs. Documentation
has been updated accordingly.

Note that the old checkfile should not be moved to the previous location
on upgrade since this will cause false negatives due to the above
arguments. A message should appear on upgrade (pkg_postinst or similar).

svn path=/trunk/gentoolkit/; revision=649

http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=4138f5b1b6dbcf1042663a45b3eae1e652bfc9be
getminupgrade: fix documentation and backtrace

Bug 281101: Fix a backtrace introduced in r647. in getminupgrade the
rValue variable was still leftover and was used in a check when
glsa-check was run in --emergelike mode and more than one upgrade atoms
existed.

Also, update the API documentation to reflect changes back then.

svn path=/trunk/gentoolkit/; revision=671

http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=2419943820ac8fb90bdf9bb5d2064a6ccdfec804