[OpenAFS] Re: Red Hat RPM packaging

[Andrew Deason]

Sorry for the delay; I've just been preoccupied.

On Thu, 04 Sep 2014 23:36:16 +0100
Karanbir Singh <mail-lists@karan.org> wrote:

> On 09/04/2014 02:43 PM, Jeff White wrote:
> > I'm not very experienced in making packages but what would be nice
> > is if there was an OpenAFS repo all by itself.  This way
> > CentOS/RHEL/Scientific Linux/Whatever could just add that repo and

Just a note: SL already has their own openafs packages and their own
repository to put it into. That is, as I mentoned above we can't put
openafs into "RHEL itself" or "EPEL itself" because of their policies,
but for SL you can do that. (Stephan maintains those packages.)

> > install away.  Additionally this makes it easy for
> > Satellite/Spacewalk users to add the repo to their servers to push
> > out to their systems (much in the way can be done with Dell's repo
> > for example).
> > 
> > Would the CentOS Project be willing to host a dedicated OpenAFS repo
> > rather than using CentOS' Extras repo?
> 
> Absolutely. One way this might work is that we can run the OpenAFS
> effort part of the Storage SIG ( which is glusterfs and ceph at the
> moment ). They are going to try and consolidate into a single
> storage-related repo, but if there is a need to, they will split the
> contents into repos per project.
> 
> We can then build centos-release-<project-name> rpms that we drop into
> CentOS-Extras/, this is then available via yum to everyone running the
> distro ver/arch that the project intends to support; and the -release
> delivers the yum repo configs, keys etc needed.

That sounds fine to me. I'm not sure I see the benefit of this over just
putting openafs packages directly in centos extras; it seems like either
way the packages are just as useable or unusable on RHEL. But if it is
superior for some reason, that sounds okay.

> > Out of curiosity, how much data would such a repo have to hold?

For reference, the current RHEL6 RPMs hosted on openafs.org for 1.6.9
take up about 47M, which includes a lot of different kmods.

> As long as we dont need to replace anythig shipped in the distro, it
> shouldnt be too much. I dont know how the kmod's work and if they are
> built to handle kabi-whitelists etc,

The kabi whitelisting mechanism doesn't really "work" for us. It has
broken in the past and we're not keen on relying on it because of that.
So ideally we would try to build kmods for every single kernel version,
or at least as close to that as is possible. I'm not really clear if
it's possible to actually disable it, but we would want to have a lot of
kmod packages.

Specifically by "not work", I mean, we've had a kernel receive a minor
update that was supposed to not break kabi compatibility, but it broke
us, and it was fixed by just building against a newer kernel. But as I
mentioned above, this is already a problem, so if we're still stuck with
it, we're not worse off.

-- 
Andrew Deason
adeason@sinenomine.net