OK, I see what you mean. However, they do that -- for the "stable" 1.4.12 release for UNIX, and for 1.5.77 for *Windows*, since 1.5.77 is the stable release for Windows.
1.5.77 on UNIX has been a moving target, and thus, there is not the same collection of binary rpms/packages on openafs.org. This all ties back to the complex discussion at the conference about the state of various releases, and the plan for normalizing this over the next year or so. The goal is to get everything to a common 1.6.* stable release, but I'm sure what the state of that is. Once 1.6.something is the stable release, then we'll see an update to the binary packages, but until then, people are on their own. On Fri, Oct 8, 2010 at 3:19 PM, David A. Desrosiers < [email protected]> wrote: > On Fri, Oct 8, 2010 at 3:14 PM, Phillip Moore <[email protected]> > wrote: > > The AFS community isn't able to get aligned with the distros, for > political > > more than technical reasons. Because the openafs license "taints" the > > Linux kernel, AFS will remain on the outside for the forseeable future, > for > > most of the Linux distros. > > That's not what I was saying... they can continue to have their own > repository, but they need to have the releases they produce, aligned > with the key releases of the core distros, and have a yum/apt repo set > up to support those distros. > > I'm not suggesting that OpenAFS be part OF the distros, I'm saying > they need to work WITH those distros, to make an installable package > available (including all required dependencies that align WITH those > packages, matching the correct distro versions) which can be included > as a third-party repository in a standard yum or apt config. > > Dozens and dozens of projects do exactly this today with > conflicting/incompatible licenses (Skype, NoMachine, etc.). > > It just requires that someone start lining up with how the distros are > moving, and make the packages work with _those_ distros, not as a > source-built add-on that requires out-of-band hacking of packages, > repositories or adding source-built packages to a distro which are > impossible to track or remove cleanly (no upgrade path, no dependency > management, etc.) > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
