No, because it just wasn’t your bone to pick. 
Don’t use ‘zypper dup’ all the time. Reason: ‘dup’ is for distupgrade. Moving to TW sort of is, updating isn’t.
I very definitely had problems with pango before I changed the priorities. That’s why I changed. So I have avoided at least that problem.
That’s why I believe dist-upgrade is the appropriate way. Updating (e.g. zypper up) doesn’t normally allow vendor change. Upgrading with zypper dup does allow vendor change. IIRC Tumbleweed repo (OBS) is a different vendor to openSUSE distribution repos, therefore by design vendor change is expected.
Some time ago I also used PCLinuxOS, claiming to be a rolling distro. Then, users were told to wait and install the big batches of “updates” together as their packages were all tested together i.e. rather like a system upgrade. The impatient ones didn’t, got in a real mess, were reprimanded by forum regulars (I wasn’t one), often needing to re-install, and learned their lesson the hard way.
So what do you think made pango unique at that instant on your system? We probably upgraded over different timescale and pattern (my install and upgrade being fairly recent), and I didn’t experience a problem.
To move to TW ‘dup’ is needed. And not once, since f.e. Libreoffice, KDE, GNOME arrive later in the TW repos. SInce a vendor change was not issued for those packages (impossible, since they ‘aren’t’ in TW), you’ll have to force the vendor change, either through Yast’s ‘switch system packages’ to the TW repo, or through ‘zypper dup --from TW’. But AFAIK that’s the exception.
I tested this weekend on a real machine. Installed 12.3, changed basic repos to ‘current’, then did ‘zypper dup’. This did not result in what I call a ‘move to TW’. A ‘zypper dup --from TW’ did. The latter also did not give dep warnings/errors.
On my laptop I have used ‘–from TW’ a couple of times, like when GNOME, KDE and so on arrived in TW. For the rest, just plain ‘zypper up’. Despite all the sandboxing the system on the laptop is stable.
Yes. Once upon a time, the wiki portal for Tumbleweed (then produced by Greg) said to use “zypper dup --from Tumbleweed” for that very first upgrade, and subsequently to use plain “zypper dup”. The “–from” just restricts it to the specified repos, while dependencies can also source from other enabled repos.
Some considerable time later, the wiki article was reworked, and --from was dropped [for that first upgrade], in favour of a plain “zypper dup” plus the creatiion of a Tumbleweed.conf file in /etc/zypp/vendors.d/ directory to allow for vendor change (see wiki for details).
BTW, although that is the recommendation in the wiki, on my most recent install I forgot to set up that Tumbleweed.conf file. I probably used “–from” but don’t recall exactly (KDE and LO were in Tumbleweed repo), and definitely only used plain “zypper dup” for all subsequent upgrades.
And not once, since f.e. Libreoffice, KDE, GNOME arrive later in the TW repos. SInce a vendor change was not issued for those packages (impossible, since they ‘aren’t’ in TW), you’ll have to force the vendor change, either through Yast’s ‘switch system packages’ to the TW repo, or through ‘zypper dup --from TW’. But AFAIK that’s the exception.
I’ve never had to force a vendor change for LO, KDE, or Gnome, with just the supported repos attached and a plain “zypper dup”. If the odd package remains sourced from oss or update repos then I’m not paranoid about that.
I tested this weekend on a real machine. Installed 12.3, changed basic repos to ‘current’, then did ‘zypper dup’. This did not result in what I call a ‘move to TW’. A ‘zypper dup --from TW’ did.
Also because you didn’t implement /etc/zypp/vendors.d/Tumbleweed.conf? If you had, then zypper dup should have worked (according to the wiki).
On my laptop I have used ‘–from TW’ a couple of times, like when GNOME, KDE and so on arrived in TW. For the rest, just plain ‘zypper up’. Despite all the sandboxing the system on the laptop is stable.
So you got away with it. According to the zypper man page, “zypper up” would allow vendor change if you implemented /etc/zypp/vendors.d/Tumbleweed.conf, so I wonder if you did that?
In any case, it’s much easier to explain the supported method of regularly upgrading with plain “zypper dup” (as in the wiki) to a new tumbleweeder, than one involving different uses of dist-upgrade and other zypper options. Even if sometimes the odd problem occurs.
The explanation, I think from gregkh, given on the factory mailing list, was that the version numbering for the Tumbleweed repo is not consistent with that for the standard repo. In the case of pango, the Tumbleweed version had a lower version number than the standard version, even though it was newer. Setting repo priorities seems to avoid this problem, by implicitly preferring Tumbleweed versions to standard versions.
Thanks for the answer. If that was the issue and it happened significantly more than it has so far, then I think the use of increased priority at least for Tumbleweed repo might be necessary, and preferably supported. However it’s not the case right now, and would need to be included in the maintainer’s testing.
I’m far less likely to use “zypper dup --from” as I’ve seen too many issues when testing it on a dry run with option “-D”. The use of multiple kermels is effectively disabled using “–from Tumbleweed”. The repo contains only a single kernel version anyway, --from is designed to avoid conflicting repos, and obsolete kernels also get removed.