[OpenAFS] additional OpenAFS 1.6.9 binaries available

[Stephan Wiesand]

On Jun 25, 2014, at 18:16 , Jeffrey Altman wrote:

> On 6/25/2014 11:39 AM, Dave Botsch wrote:
>> At the very least, I'd like to see a spec included in the source so
>> that one can rebuild on one's own the binaries from the source (on at
>> least the base RHEL and current Fedora).
> 
> The underlying issue is what should be in the spec file and who is going
> to maintain it?   Its not like there is a single distribution of Linux.
> Each distribution has its own requirements and preferences for how
> applications, daemons, and kernel modules should be installed and
> configured.

Having a reference spec for one platform in the tree would still be good.
I do share your concern regarding its maintenance though.

> The spec file currently in the OpenAFS tree is in violation of many of
> the Fedora and RHEL guidelines.  For starters, the use of transarc paths
> instead of FHS is a big issue.  For RHEL7 there is significant work that
> needs to be done to produce compliant packaging.

Strictly speaking, the FHS "violation" is not an actual issue unless /usr
is immutable. And that's only just begun to be a concern with "atomic"
deployment / rpm-ostree. And that's in its infancy. And at least for client
systems, a workaround seems feasible. But I agree that that's not the way
forward in the long run.

> For Fedora, the rpm fusion packaging is much closer to what the
> community wants to see.

I'm not sure. Significant parts of the existing community may still be
using transarc paths and not keen on this change. Attracting new
community members with transarc paths is probably difficult though.

>   For RHEL, the ElRepo packaging is much closer
> to what is required for RHEL7.

RHEL7 itself doesn't require anything special. It's rather us saying
that on a new platform (with 10 years of support life) we don't want
to continue with something that's already looking baroque.

But yes, it would be good to leave the packaging to downstream.

Alas, the ELRepo packaging handles the kernel modules in a way the
OpenAFS developers clearly disapprove of, and I'm not sure that's
fixable.

>  It is our view that given available
> resources that downstream distributions should package OpenAFS and end
> users should work with the downstream distributions to determine how
> those packages should function.
> 
> One of the primary benefits of this approach is that downstream
> packagers do not need to wait for new OpenAFS releases to distribute
> packages that support new kernel releases or address other distribution
> specific functionality.
> 
>> IMHO, not offering binaries and telling users to go someplace else is
>> not perceived as friendly to the users... UNLESS.. there is a direct
>> pointer to said trusted 3rd party binary builder. Especially if binaries
>> are available for Mac and Windows... it comes off as a "screw you" to
>> linux users.

If that's what my previous message conveyed, I'm really sorry.

But note that we only ever provided a spec for EL/Fedora, and uploaded
binaries for those built from that spec - and for SUSE built from
something entirely different. Debian/Ubuntu packaging has been done
downstream for a long time, and the same holds for other distributions.

On the other hand, "configure; make; make install" is still supposed to
work on any Linux distribution. And that's all several other platforms
ever had.

> Funny you should bring up OSX and Windows.   For OSX the packaging is
> now two OS revisions out of date.  Installers cannot be built for
> Mavericks or Yosemite with current build tools.   The installers can
> only be built using the development tool chain for Mountain Lion.

And no more volunteers for doing it either. I'm really glad Ken H. helped
us out with such an installer so we have something that can be installed
"easily" on Mavericks when I approached him. But that's hardly a sustainable
model.

> On Windows, the packaging scripts have not been updated in almost six
> years.  They cannot be built using current versions of the WiX tool
> chain.  They do not support merge modules and do not support installing
> 32-bit and 64-bit components in the same msi.
> 
> Installation packaging is hard.  In some ways it is harder than writing
> the file system.  Both the OSX and Windows installation packaging
> requires a total rewrite.  If there was a downstream source that could
> take responsibility for doing that work, we would ask them to do so.
> The way things are at present OSX and Windows are simply limping along.
> 
> Jeffrey Altman

-- 
Stephan Wiesand