On 05/01/2015 09:46 PM, Stephan Kulow wrote:
Am 01.05.2015 um 14:08 schrieb Jan Engelhardt:
On Friday 2015-05-01 13:20, Stephan Kulow wrote:
Am 01.05.2015 um 11:34 schrieb Jan Engelhardt:
In particular though, regarding package selection, I do have the following constraints:
- no downgrades relative to the versions that already were present in 13.2, even if that means that converging to openSUSE:Essence takes longer. I am not going to accept the backstep from kernel 3.16 to 3.12 :-) It's a hard to swallow pill, but the question is basically: for how long can *you* maintain 3.16? kernel.org doesn't for you nor does SUSE. Before it's misunderstood: the 3.16 kernel in 13.2 is maintained as long as 13.2 is - replace 3.16 with 4.$SOMERANDOMNUMBER in my argument :) The point is that there are features that you cannot backstep from. For example, kernelnewbies.org says about 3.16: "In this release, XFS has added a btree that tracks free inodes. This feature adds does not change existing on-disk structures, but adds a new one that must remain consistent with the inode allocation btree; for this reason older kernels will only be able to mount read-only filesystems with the free inode btree feature."
Whatever kernel is picked for 13.3, if it is less than 3.16, people could run into a problem for something that worked before. I have not found the new flags on my XFS superblocks yet, but that does not have to mean anything.
Can we agree on: 13.3 kernel needs to be able to cope with filesystems created with 13.2
and leave out version numbers?
Greetings, Stephan
Out of interest would the maintenance burden be much less if openSUSE 13.3 used one of the upstream LTS kernels, then only applied the SUSE specific patches (as opposed to bugfix / driver updates)? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org