On Tue, Sep 30, 2014 at 4:41 PM, Andrew Deason adeason@sinenomine.net wrote:
On Fri, 26 Sep 2014 14:34:37 -0400 ross smith gaurdro@gaurdro.net wrote:
(For anyone who cares and doesn't know, I am an upstream developer, and was advocating for the RPM packaging to move downstream.)
Glad to have someone from the upstream looking at this too.
- 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.
I was going to make this the first entry in the changelog that it was forked from the packaged 1.6.9 openafs.org spec file. I imagine the spec file is going to land in a centos.org git repo at some point and its origin can be noted at that push as well.
- The 'compat' subpackage has been removed, but I'm not sure why.
I was pruning from the original package and it ended up empty, so I dropped it instead of figuring out what should be included. I assumed it would come up before it was stabilized if someone cared about it. I wouldn't be opposed to recreating it for <7 with or without the transarch paths. I think RHEL/CentOS 7 is a big enough change that starting as clean as possible would be worthwhile.
- 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.
At least for userspace I think the complexity is small enough to support
both 6 and 7. I don't think a final destination for the packages has been decided yet. I'd like to have RHEL/CentOS 6 packages available and leave it up to the sysadmins to decide when makes sense for them to migrate. I'm certainly not discounting el7 as an important build target though.
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?
This might be a good argument for setting up a Storage SIG mailing list even if we do most of our discussion here.
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?
I understand there's some infrastructure already in place with CentOS to rebuild packages when the kernel package updates. The updated packages would happen at the repo level, not at the system level.
So, how do we determine what
kernels to build kmods for?
I've not heard a definitive answer on this myself. I suspect that there will be at most one kernel-devel package installed at build time, which should simply things a bit. I haven't dug around in koji to see if my suspicions are correct, however. This would be a good topic for the meeting tomorrow.
Ross Smith
gaurdro@gaurdro.net