On 1 May 2015 at 14:08, Jan Engelhardt <jengelh(a)inai.de> wrote:
The point is that there are features that you cannot
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
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org