summaryrefslogtreecommitdiff
path: root/test/integration/test-prevent-markinstall-multiarch-same-versionscrew
AgeCommit message (Collapse)Author
2016-05-11respect user pinning in M-A:same version (un)screwingDavid Kalnischkies
Using Pkg.CandVersion() here is wrong as its implementation will return a candidate based just on the default policy settings ignoring user preferences and otherwise set candidates (aka: it sidesteps the pkgDepCache). This causes M-A:same libraries to be detected as screwed even through they aren't, so that they end up being kept back. Reported-By: Felipe Sateler on IRC
2015-12-19tests: support spaces in path and TMPDIRDavid Kalnischkies
This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore
2015-08-17Fix the test suite againJulian Andres Klode
Gbp-Dch: ignore
2015-03-16test exitcode as well as string equalityDavid Kalnischkies
We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore
2014-10-23tests: support 'installed' release in insertpackageDavid Kalnischkies
It is sometimes handy to have an installed package also in the archive, but this was until now harder than it should as you had to duplicate the lines, which is especially dangerous while writing the tests as it easily happens that these two lines divert and so the same-but-different version detection kicks in. Git-Dch: Ignore
2014-09-27fix progress output for (dist-)upgrade calculationDavid Kalnischkies
Previously, we had a start and a done of the calculation printed by higher-level code, but this got intermixed by progress reporting from an external solver or the output of autoremove codeā€¦ The higherlevel code is now only responsible for instantiating a progress object of its choosing (if it wants progress after all) and the rest will be handled by the upgrade code. Either it is used to show the progress of the external solver or the internal solver will give some hints about its overall progress. The later isn't really a proper progress as it will jump forward after each substep, but that is at least a bit better than before without any progress indication. Fixes also the 'strange' non-display of this progress line in -q=1, while all others are shown, which is reflected by all testcase changes.
2014-03-13do not configure already unpacked packages needlesslyDavid Kalnischkies
The unpack of a M-A:same package will force the unpack of all its siblings directly to prevent that they could be separated by later immediate actions. In commit 634985f8 a call to SmartConfigure was introduced to configure these packages at the time the installation order encounters them. Usually, the unpack order is already okay, so that this 'earlier' unpack was not needed and if it wouldn't have been done, the package would now only be unpacked, but by configuring the package now we impose new requirements which must be satisfied. The code is clever enough to handle this most of the time (it worked for 2 years!), but it isn't needed and in very coupled cases this can fail. Removing this call again removes this extra burden and so simplifies the ordering as can be seen in the modified tests. Famous last words, but I don't see a reason for this extra burden to exist hence the remove. Closes: 740843
2013-07-11prevent MarkInstall of unsynced Multi-Arch:same siblingsDavid Kalnischkies
Multi-Arch: same packages can be co-installed, but need to have the same version for all installed packages (aka "siblings"). Otherwise the unsynced versions will fight against each other and the auto-install as wel as the problem resolver will later have to decide between holding the packages or to remove one of the siblings (usually a foreign) taking a bunch of packages (like the entire foreign setup) with them. The idea here is now to be more pro-active: MarkInstall will fail for a package if the siblings aren't synced, so we don't allow a situation in which a resolver has to decide if to hold or to remove-upgrade under the assumption that the remove-upgrade decision is always wrong and doesn't deserve to be explored (expect valid out-of-syncs of course). Thats a pretty bold move to take for a library which is used by different solvers so this check is done in IsInstallOk and can be overridden if front-ends want to.