On 1 May 2015 at 14:08, Jan Engelhardt <jengelh@inai.de> wrote:
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.
I have already tested this. The current SLES 12 kernel can *already* support opensuse 13.2 XFS volumes SUSE do not ship 'vanilla' kernels (or other components) with SLE. They spend a lot of effort adding/backporting features - I think we to stop thinking the version number is a good indicator of a packages capabilities.
- kernel and glibc shall be refreshed for releases.
Why? Any technical reasons or just so?
No technical reasons, just practical ones. Sometimes there is new clunky hardware that needs something that is not 2 years old. Or because they made working with btrfs more endurable (fast device replacement in e.g. 3.19) for everyone. I kind of like how gcc does its multiversioning: it allows you to optionally install a newer one _from the same repository_. That one may be an unmaintained Tech Preview, but that would be good enough for me. The only issue is that kernel-*s share the same package name while gcc does not, so that has some implications how OBS selects them for build :/
See my above comment - I think we need to check what the sources we have now can actually DO before judging whether they do what we want.. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org