On 6/15/23 06:18, Carlos E. R. wrote:
On 2023-06-15 07:05, Andrei Borzenkov wrote:
On 14.06.2023 23:55, Christian Boltz wrote:
That leaves 1% of special cases where "up" makes sense. For example, if someone really wants to update a specific package without upgrading the whole system - which is a very valid approach if you want to check if this package fixes a specific issue. In this case, you really don't want 142 more packages upgraded that might randomly influence the result.
And this particular Tumbleweed snapshot may have rebuilt the whole distribution using new gcc/boost/openssl/whatever so you end up with weird mix of software using old and new binaries "randomly influencing the result".
The problem is somewhat unique to SUSE. The whole workflow of SUSE upgrades depends on using out-of-band "zypper dup" actions instead of maintaining correct package dependencies. This was OK for infrequent upgrades between service packs/stable releases but it falls apart with Tumbleweed where "each snapshot is new release".
Maybe if using tumbleweed snapshots (whatever the name is). Huh, but there would not be updates inside a single snapshot, and to change to another means a dup.
And that is one of the reasons why I use the build history snapshots. That allows me to control which build I am on and not have to worry about these issues because the TW build does not change until I decided to change it. The main caveat is that there are only 20 history builds therefore, once #21 is published the oldest falls off so if you are on that, then you have to switch to one of the remaining 20 builds. Not a big deal as I generally update before that happens. -- Regards, Joe