aboutsummaryrefslogtreecommitdiffstats
path: root/t/gpghome
diff options
context:
space:
mode:
authorGustavo De Nardin <spuk@mandriva.org>2007-03-24 10:04:55 +0000
committerGustavo De Nardin <spuk@mandriva.org>2007-03-24 10:04:55 +0000
commit54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e (patch)
treeaf734e0770ab788e18db2baaf0900b35aa7aba56 /t/gpghome
parent55398d96968ca129b0229f6087aa9bc393a881a4 (diff)
downloadmga-youri-core-54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e.tar
mga-youri-core-54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e.tar.gz
mga-youri-core-54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e.tar.bz2
mga-youri-core-54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e.tar.xz
mga-youri-core-54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e.zip
Replaced old code for package section discovery (Mandriva_upload::_get_section()).
This should fix bug #28719. The new code searches for specific versions first, using only source media when it exists. This should solve the search order dependency when there are no duplicates of a package with the same version-release in more than one section. The previous code depended on search order to find a section, preferring source medias, but still searching in binary medias when a section was not found in the source media, and had a hack to avoid finding /testing sections. This /testing avoidance hack caused packages submitted to /testing subsections to always end up getting section 'contrib/release' (fallback..), and this in turn made Youri::Submit::Action::Archive to get confused and remove older packages in other-than-submitted sections. When a package was submitted to a non-/testing section, and a different section with older version of that (binary or source) package came first in the search. For example: package submitted to main/backports, existing also in main/release, with main/release appearing first in search list, then the section for it would be found to be main/release, and Youri::Submit::Action::Archive would remove the older package there. Another problem would be if the first package processed was the SRPM, with a "bad" section early in search, the older SRPM in the "bad" section would be removed, and then binaries on other sections would not be removed, due to the search preferring the section in which the new SRPM is (the right one). Etc..
Diffstat (limited to 't/gpghome')
0 files changed, 0 insertions, 0 deletions