[Lustre-discuss] Lustre-1.9.210: mkfs.ldiskfs?

[Brian J. Murrell]

On Fri, 2009-07-03 at 00:00 +0200, Andreas Dilger wrote:
> 
> I wouldn't support a BuildRequires, since I've had enough trouble with
> those in the past that I don't like them at all.

Well, if they are needed and used properly, they are good as they
prevent you from going down an rpmbuild path only to have it bail 90% of
the way done because something needed is not installed.

Indeed however they can be troublesome with the kind of spec files we
still have around -- the single spec trying to satisfy multiple distros;
those are just generally trouble.  The kinds of trouble they cause is
exactly what has led to us abandoning our own kernel spec and using each
vendor's own kernel spec now.  But I digress.  In any case, I think Jim
and I have discussed in this thread elsewhere that a BuildRequires on an
ldiskfsprogs is not really the right tool here anyway.

> However, we've been shipping e2fsprogs with a "Provides: ldiskfsprogs"
> for long enough (at least 1.40.5.sun1, I haven't checked earlier) that
> we could consider also add a "Requires: ldiskfsprogs" to our lustre .spec

I don't think that would solve the original problem though, as my
proposal for (conditionally, if the corresponding configure flag was
used) adding Requires: ldiskfsprogs to lustre.spec would be meant to
really require an ldiskfs branded e2fsprogs (i.e. with executables named
s/ext3/ldiskfs/).

> so that we are sure that a Lustre-aware e2fsprogs is available.

I certainly wouldn't disagree with doing this, but I think that's a
different problem and solution pair.  Certainly, having both e2fsprogs
and ldiskfsprogs RPMs Provide: lustre-e2fsprogs and having the lustre
packages Require: lustre-e2fsprogs would be good, but orthogonal to OP's
problem.

> The one
> problem is that e2fsprogs/ldiskfsprogs is NOT required on the client,
> and I wouldn't want to force this on every client.

Sure.  It should only be required by servers.  But given that we lack a
lustre-servers separate package, it gets tricky considering the servers
package could be installed on what's really a client.

This all begs the lustre packaging (i.e. the rpm split up) to be
overhauled.

> I don't think we
> have separate server RPMs, so I don't know if there is an easy answer.

Heh.  What he said.  :-)

> Note also that the Lustre e2fsprogs doesn't provide a "mkfs.ldiskfs",
> "fsck.ldiskfs", or any similar tool.  That is only in LLNL's RPM, and
> the "--with-ldiskfsprogs" option shouldn't really be used by anyone
> else.

Well, it is there.  I don't know about others shouldn't be using it and
whatnot, but if the option is there, it should be complete (well as
complete as it could reasonably be), imho.  Given our current rpms
though, it probably already is.

Just fodder for the future.  :-)

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20090702/cea587b9/attachment.pgp>