On Tue, 2008-03-18 at 12:28 -0700, Michael Jennings wrote: 
> On Tuesday, 18 March 2008, at 12:15:34 (-0700),
> Christopher Irving wrote:
> 
> > Now, if you removed line 651 and 653 from the new spec file it works
> > for both cases.  You wont get the files listed twice error because
> > although you have the statement %dir %{_prefix} on line 649 you
> > never have a line with just %{_prefix}.  So the _prefix directory
> > itself gets included but not all files underneath it.  You've
> > handled that by explicitly including all files and sub directories
> > on lines 672-681 and in the runtime.file.
> 
> The only package which should own %{_prefix} is something like setup
> or filesystem in the core OS package set.  No openmpi RPM should ever
> own %{_prefix}, so it should never appear in %files, either by itself
> or with %dir.
> 


Well you're half correct.  You're thinking that _prefix is always
defined as /usr.  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. 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.

> > Going back to the original spec file, the one that came with the
> > source RPM, the problems where kind of reversed.  Building with the
> > 'install_in_opt 1' option worked just fine but when it wasn't set
> > you got the files listed twice error as I described in my original
> > message.
> 
> "files listed twice" messages are not errors, per se, and can usually
> be safely ignored.  Those who are truly bothered by them can always
> add %exclude directives if they so choose.
> 
> Michael

It can't be safely ignored when it causes rpm build to fail.  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.  It's
much easier and makes a lot more sense to remove the source of the
duplicated inclusion.  Which is exactly what they did and why that's no
longer the problem with the new spec file.

-C  

Reply via email to