On Tue, 2019-01-08 at 13:08 +0100, Jan Luca Naumann wrote: > Hey, > > thank you for the upload and your work. I am sorry that I did not manage > to upload the new version due to too much other workload.
There's nothing to be sorry about. I usually check that out-of-tree module packages are up-to-date as we approach the freeze. This time I took the time to update some of them too. > I have seen that your delete the dependency on linux-kbuild. I have > added it to avoid transition of the aufs-packages to testing before the > linux package is available in the requested version. One time there was > the problem that the aufs-package already migrated but the linux package > had some RC-bug. That's a good point, which perhaps should have been recorded in the git commit log or the changelog, so that I didn't think it was a mistake. :-) To expand on what I wrote in the changelog: - In order to use aufs-dkms, it's necessary to install a linux-headers package for a suitable kernel version. - If that linux-headers package is one built by Debian, it already depends on linux-kbuild-4.19. - However, if it's a custom package built using "make deb-pkg", it includes all the kbuild scripts and other tools. Then there's no need to install linux-kbuild-4.19 at all. But I suppose the extra dependency doesn't matter that much. You're the maintainer and should of course add it back if you still think it's justified. It's unfortunate that backwards-compatibility for aufs is maintained through separate git branches rather than conditional code. None of the other out-of-tree modules packaged for Debian seem to be like this. I wonder if it would be possible to support multiple kernel versions like this: - When preparing the source package, run a script to generate diffs from the latest upstream branch to each older branch that's still maintained, and add those under the debian directory. - When building the binary packages, include the diffs in aufs-dkms. - When building under dkms, start by applying the appropriate diff for the target kernel version. (You might need to copy-and-patch, as I'm not sure whether dkms will unpack the source again when building for a different version.) I haven't spent a whole lot of time thinking about this, so this might well be impractical. Ben. -- Ben Hutchings Every program is either trivial or else contains at least one bug
signature.asc
Description: This is a digitally signed message part
