On Fri, 26 Sep 2014 14:34:37 -0400 ross smith gaurdro@gaurdro.net wrote:
I have been working on reworking the upstream spec file to work with centos. I've been keeping track of my progress on my github page [1] and I welcome pull requests if you find a problem.
Thanks for doing this. I had some comments on this I wanted to write down somewhere, so I'll just bring that up here; let me know if any such discussion should move elsewhere. I should be at the meeting tomorrow, too, where any of this can be discussed in realtime if anyone would like. (For anyone who cares and doesn't know, I am an upstream developer, and was advocating for the RPM packaging to move downstream.)
- I guess it's too late for this for the commit history, but it would be nice if it was noted anywhere where the original spec file came from before any modifications. e.g. what openafs.git git commit hash, or if it just came from the upstream openafs 1.6.9 source tarball release.
- The 'compat' subpackage has been removed, but I'm not sure why. This seems like a very low level of effort to maintain, but this is actually useful for compatibility with old tooling.
- The 'transarc' paths have been removed, which is good, but a compatibility subpackage with symlinks for the old 'transarc' paths would be very useful. This is perhaps more important than the 'compat' package referenced above, since transarc paths are used in all existing upstream RHEL/CentOS packaging. I was thining of a 'transarc' subpackage, but I guess there's no reason this couldn't just be rolled into the 'compat' subpackage.
- Just to note: I originally thought that CentOS would just provide packages for RHEL/CentOS 7, and that users of 6 could use the existing upstream packaging. That way, the transition of moving from openafs.org to centos.org RPMs would occur when migrating from 6 to 7, and there would be no migration within the same base system. I just thought it would be easier for existing users this way (and it can make the spec file a bit simpler), but I don't know if you agree. At the very least, I thought 7 would be a priority, since upstream will not be providing 7 packages.
Also, who should the "packager" be set to? Does a single person volunteer to be the official maintainer of the packaging, or should it be assigned to the Storage SIG or something like that?
I have pulled out all of the code related to the building the kmod, as I think that should at least be rewritten from scratch and quite possibly should live in it's own spec file.
That sounds good, but do we know how the kmod builds are going to work at all? My understanding is that we cannot rely on detecting what kernel headers are installed, and we also cannot accept kernel versions to build against via rpmbuild parameters. So, how do we determine what kernels to build kmods for?
Or I think I heard some mention of dynamically building kmods via a kernel trigger or something, which sounded a lot like DKMS. I'm not clear on how that would be beneficial over DKMS...? Some users do want more traditional kmod packages, but most should be satisfied by DKMS if that's the only practical option in the existing build framework.