On Tuesday, 18 March 2008, at 18:18:36 (-0700),
Christopher Irving wrote:
> Well you're half correct. You're thinking that _prefix is always
> defined as /usr.
No, actually I'm not. :)
> But in the case were install_in_opt is defined they have redefined
> _prefix to be /opt/%{name}/%{version} in which case it is fine for
> one of the openmpi rpms to claim that directory with a %dir
> directive.
Except that you should never do that. First off, RPMs should never
install in /opt by default. Secondly, the correct way to support
installing in /opt is to list the necessary prefixes in the RPM
headers so that the --prefix option (or the --relocate option) may be
used at install time. OpenMPI already has hooks (IIRC) for figuring
things out intelligently based on invocation prefix, so it should fit
quite nicely into this model.
Obviously RPMs only intended for local use can do anything they want,
but RPMs which install in /opt should never be redistributed.
> However I think you missed the point. I'm not suggesting they need
> to a %{_prefix} statement in the %files section, I'm just pointing
> out what's not the source of the duplicated files. In other words
> %dir %{_prefix} is not the same as %{_prefix} and wont cause all the
> files in _prefix to be included.
That's correct.
> It can't be safely ignored when it causes rpm build to fail.
The warning by itself should never cause rpmbuild to fail. If it
does, the problem lies elsewhere. Nothing in either the rpm 4.4 nor 5
code can cause failure at that point.
> Also you don't want to use an %exclude because that would prevent
> the specified files from ever getting included which is not the
> desired result.
If you use %exclude in only one of the locations where the file is
listed (presumably the "less correct" one), it will solve the problem.
Michael
--
Michael Jennings <m...@lbl.gov>
Linux Systems and Cluster Admin
UNIX and Cluster Computing Group
