[19.07] ksmbd: update to 3.2.0, ksmbd-tools: update to 3.2.6

[Andy2244]

Maintainer: me
Compile tested: arm (19.07)
Run tested: arm/qemu (19.07)

Description:

• ksmbd: update to 3.2.0
• ksmbd-tools: update to 3.2.6
• refresh patch

[luizluca]

What I don't like about kmod changes is that the updated kmod package will require a not released kernel (the one from 19.07-snapshot SDK). So, no one with a stable release will cleanly install ksmbd. It will need to force deps.

[Andy2244]

What I don't like about kmod changes is that the updated kmod package will require a not released kernel (the one from 19.07-snapshot SDK). So, no one with a stable release will cleanly install ksmbd. It will need to force deps.

Yes i understand the problem, but what do you want me to-do? Not update kmods on the stable release?

[luizluca]

I think that no updates that breaks compatibility with existing release kmod package should be accepted on a stable release. You'll have a newer userland code that requires a new kmod package, only built for a kernel from a 19.07-snapshot branch that does not officially publishes packages.

At this time, we have:

• kmod-fs-ksmbd - 4.14.180+3.1.3-1
• ksmbd-server - 3.2.6-1

And I guess 3.1.x is incompatible with 3.2.x. The result is that no one can install ksmbd anymore until the next dot release (and only after they upgrade their firmware).

Maybe It could accept that kind of change just before a new dot release (although it will still break previous versions). At least it will get published, but it will still require existing users to upgrade the kernel before installing any ksmbd-server.

Current packages directory structure does have a subversion specific directory for kmods
(19.07.3/targets/ath79/generic/kmods/4.14.180-1-b84a5a29b1d5ae1dc33ccf9ba292ca1d). But I don't know if that directory should be touched after a release is made. Maybe we should have a 19.07.3/targets/ath79/generic/kmods-update/?

If updating kmods in a stable release is acceptable, buildbot should be updated to deal with this multiversion kernel scenario. As far as I could understand, the responsible script for building packages is https://git.openwrt.org/?p=buildbot.git;a=blob;f=phase2/master.cfg. It uses SDK built from phase1. Maybe it should have a phase3 for stable branches where it downloads every previous released SDK from that stable branch and rebuild only kmod packages, publishing each updates on each respective kmods/ directory.

Alternatively, we could keep old packages published if opkg could solve a dependency using multiple version packages, specially when the one that solves the requirement is not the last one.
In that case, an update like this one would not be effective until a new dot release happens. Those with a new kernel would install the new userland while those using older kernels will still be able to install the previous userland code.

I'm just a package contributor and a user affected by this update. As it touches sensitive areas and defines what can be updated on a stable branch, it should involve some core devs.

[neheb]

ping @namjaejeon are cifsd-utils 3.2 incompatible with module 3.1?

[namjaejeon]

@neheb module is 3.1.3 and lower versions are incompatible with ksmbd-utils-3.2.x.

1. module 3.1.3 and lower versions and utils-3.2.6 => incompatible.
2. module 3.1.4 and utils-3.2.6 => normal work fine but new follow symlink param doesn't work.
3. module 3.1.7 and higher versions and utils-3.26 => Completely compatible.