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. 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. For Fedora, the rpm fusion packaging is much closer to what the community wants to see. For RHEL, the ElRepo packaging is much closer to what is required for RHEL7. 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. 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. 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
smime.p7s
Description: S/MIME Cryptographic Signature
