On Tue, 2019-08-27 at 18:03 -0400, Robert P. J. Day wrote:
On Tue, 27 Aug 2019, Adam Williamson wrote:
> The only problem you might run into here is the 'updates-testing
> disablement trap'. When you install from a Branched pre-release, the
> 'updates-testing' repository is enabled by default.
simple solution ... any problem with just *immediately* disabling
updates-testing in situations like this? problem solved?
No, because...well, think of it like this. updates-testing is basically
'ahead' of stable, right? The distance it's "ahead" is not fixed,
it
depends on how fast updates are pushed stable, but it's "ahead" by some
distance. So at the exact point updates-testing gets disabled, if it
was previously *en*abled, you likely have something installed that's
"ahead" of the repos you have enabled.
Here's the simplest practical example. There's a library libfoo, and
dozens of packages depend on it, including moo and bar. You have moo
installed. Shortly before updates-testing is disabled, a libfoo soname
bump is sent there, so you get the new libfoo and moo installed. Then
the day after updates-testing is disabled, you do 'dnf install
bar'...but it fails, because now you're getting the 'bar' from stable,
which is built against the old libfoo from stable, not the new libfoo
from updates-testing. There is probably a new 'bar' in updates-testing
that is built against the new libfoo, but because u-t is now disabled,
you don't see it. That's the kind of problem that tends to show up.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net