diff options
author | Gustavo De Nardin <spuk@mandriva.org> | 2007-03-24 10:04:55 +0000 |
---|---|---|
committer | Gustavo De Nardin <spuk@mandriva.org> | 2007-03-24 10:04:55 +0000 |
commit | 54ac05ac9906926bbc5f2c3d047e0d2073f7fc4e (patch) | |
tree | af734e0770ab788e18db2baaf0900b35aa7aba56 /lib/Youri/Check/Resultset | |
parent | 55398d96968ca129b0229f6087aa9bc393a881a4 (diff) | |
download | mga-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 'lib/Youri/Check/Resultset')
0 files changed, 0 insertions, 0 deletions