[CentOS-devel] openafs userspace packages

On Fri, 26 Sep 2014 14:34:37 -0400
ross smith <gaurdro at 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.

-- 
Andrew Deason
adeason at sinenomine.net