Hi, On Thu, Apr 30, 2015 at 10:30:23AM +0200, Marcus Meissner wrote:
On Thu, Apr 30, 2015 at 10:18:14AM +0200, Torsten Gruner wrote: [ 8< ]
Another solution might be to mark the affected packageswith this kind of changes. And each packet has to be assessed whether a jump to the next version without consequence for the function. Can several versions are skipped? And zypper has to handle this. This is a nice feature but a dream only.
What do you mean with affected packages?
The kernel for example. At some point we had kernel-default-3.19.4-1.1.x86_64 and that got replaced by kernel-default-3.19.4-1.2.x86_64 Both make use of /boot/vmlinuz-3.19.4-1-default resulting in a file conflict.
We try to push out only "stable" and working tumbleweed snapshots and that seems to be working quite well already.
On one of my real systems this worked quite well - cause I power it on less often. But with my daily updated workstation I had trouble several times. I still have two rdsosreport.txt files stored. As it works 3 of 4 times and I don't see a pattern - sometimes booting an older kernel and calling dracut for the failing one help but sometimes I had to make use of a rescue system - and have not reported it to bugzilla yet.
My Laptop is running Tumbleweed and I have so far not have had a single troublesome status.
In the current state Tumbleweed isn't able to pass the relatives test yet. Even getting them using openSUSE 13.2 with a KDM which sets a non KDE session type with one of the recent KDE 13.2 updates is a no go for such users. All they intend more or less is to start a web browser and a text processor. And all this is for me a good reason to have regular openSUSE releases. Once every 12 months if fine. But hey, maybe the openSUSE conference will even bring a much better news to us. :) Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany