<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 30, 2014 at 4:41 PM, Andrew Deason <span dir="ltr"><<a href="mailto:adeason@sinenomine.net" target="_blank">adeason@sinenomine.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, 26 Sep 2014 14:34:37 -0400<br>
ross smith <<a href="mailto:gaurdro@gaurdro.net" target="_blank">gaurdro@gaurdro.net</a>> wrote:<br>
<br></span> (For anyone who cares and doesn't know, I am an upstream<br>
developer, and was advocating for the RPM packaging to move downstream.)<br>
<br></blockquote><div> Glad to have someone from the upstream looking at this too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- I guess it's too late for this for the commit history, but it would<br>
be nice if it was noted anywhere where the original spec file came<br>
from before any modifications. e.g. what openafs.git git commit hash,<br>
or if it just came from the upstream openafs 1.6.9 source tarball<br>
release.<br></blockquote><div>I was going to make this the first entry in the changelog that it was forked from the packaged 1.6.9 <a href="http://openafs.org">openafs.org</a> spec file. I imagine the spec file is going to land in a <a href="http://centos.org">centos.org</a> git repo at some point and its origin can be noted at that push as well. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The 'compat' subpackage has been removed, but I'm not sure why.</blockquote><div> </div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Just to note: I originally thought that CentOS would just provide<br>
packages for RHEL/CentOS 7, and that users of 6 could use the<br>
existing upstream packaging. That way, the transition of moving from<br>
<a href="http://openafs.org" target="_blank">openafs.org</a> to <a href="http://centos.org" target="_blank">centos.org</a> RPMs would occur when migrating from 6 to<br>
7, and there would be no migration within the same base system. I<br>
just thought it would be easier for existing users this way (and it<br>
can make the spec file a bit simpler), but I don't know if you agree.<br>
At the very least, I thought 7 would be a priority, since upstream<br>
will not be providing 7 packages.<br>
<br></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, who should the "packager" be set to? Does a single person<br>
volunteer to be the official maintainer of the packaging, or should it<br>
be assigned to the Storage SIG or something like that?<br></blockquote><div> </div><div>This might be a good argument for setting up a Storage SIG mailing list even if we do most of our discussion here. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> I have pulled out all of the code related to the building the kmod, as<br>
> I think that should at least be rewritten from scratch and quite<br>
> possibly should live in it's own spec file.<br>
<br>
</span>That sounds good, but do we know how the kmod builds are going to work<br>
at all? </blockquote><div> </div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, how do we determine what<br>
kernels to build kmods for?<br></blockquote><div> </div><div> 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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888"><br></font></span></blockquote><div>Ross Smith </div><div><a href="mailto:gaurdro@gaurdro.net">gaurdro@gaurdro.net</a></div></div><br></div></div>