[CentOS-devel] openafs userspace packages

[ross smith]

On Tue, Sep 30, 2014 at 4:41 PM, Andrew Deason <adeason at sinenomine.net>
wrote:

> On Fri, 26 Sep 2014 14:34:37 -0400
> ross smith <gaurdro at 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 at gaurdro.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140930/4ab26312/attachment.html>