[OpenAFS] Re: OpenAFS and RHEL5 Server 64-bit?

Axel Thimm Axel.Thimm@ATrpms.net
Wed, 8 Aug 2007 00:59:40 +0200

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 07, 2007 at 06:31:32PM -0400, Scott Ehrlich wrote:
> On Wed, 8 Aug 2007, Axel Thimm wrote:
> >On Tue, Aug 07, 2007 at 04:02:17PM -0400, Scott Ehrlich wrote:
> >>I have some dual-boot XP/CentOS 5 systems that I want to authenticate t=
o a
> >>server running RHEL 5 Server 64-bit edition, unpatched.   I want central
> >>authentication from the server, so the same home directory will appear =
> >>any account created on the server, regardless of whether the user is
> >>logging into the Windows or Linux side, even for simultaneous logins.
> >>
> >>I obtained the latest OpenAFS source from openafs.org, but compiling
> >>crashed.
> >>
> >>What am I missing?
> >
> >Have you checked out
> >
> >http://atrpms.net/dist/el5/openafs/
> >
> >It contains support for all RHEL5/CentOS5 kernels ever released.
> Not yet, but I always wonder who actually creates rpms at various=20
> distribution sites, such as rpmfind.net, dag, etc, and how it is done.

rpmfind.net is just a catalogue, dag is a repo called by the first
name of its maintainer, Dag Wieers.

> Wny don't the source organizations (i.e. abisource for abiword) create=20
> .deb and .rpms for that program, instead of having to find it at some=20
> random site, not knowing who has really done what to create the rpm at th=
> repo site.

Well, that's an old dream that unfortunately hasn't come true yet. The
main reason is that while say Red Hat and SuSE both use rpm as a
format their style and policies differ a lot. It isn't impossible to
write specfiles for both in trivial hello-world packages, but openafs
is far more involved (any project doing kernel modules is by
definition in the advanced packaging category).

In a nutshell: packaging is still far from being portable, so that
distro-agnostic upstream authors have a hard time to get all distro
details sorted out. That's why the distro's vendor or specialized 3rd
party repos can offer packages at all.

But your confusion on who's who at least in the enterprise land is
justified, one does want to know the sources and the fragmentation
makes it a pain. The good news is that the major RHEL/CentOS/SL 3rd
party repos agreed to fusion into one, so your sources will greatly
reduce :)
Axel.Thimm at ATrpms.net

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (GNU/Linux)