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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
