rpms/flumotion/devel flumotion.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Michael Schwendt]

On Mon, 25 Apr 2005 17:17:18 +0200, Ralf Corsepius wrote:

> These are different %{_datadir}'s. 

This is splitting hairs.

/usr/lib/rpm/macros:
%_datadir                %{_prefix}/share

%_datadir is _the_ global definition of datadir as we know it. Where we
override it on a per package basis, we break a global default. Nobody
cares if that also breaks a package->file dependency. It would be expected
behaviour. A packager [and everybody who rebuilds a package] should have
very good reason to redefine %_datadir.
 
> > If both packages are rebuilt with a different %_datadir, they would
> > still work.
> 
> Here you say it: "if .. both .. packages". I.e. if the default value for
> %_datadir as being provided by rpmbuild changes globally.

> That's why an "FE/FC" build system will not notice the difference.

We are FE and build for FC. Expanding %_datadir into a hardcoded
/usr/share just because we know that %_datadir expands into /usr/share for
FC and puts a script into an absolute path, doesn't add any value. The
resulting dependency in the binary package is on /usr/share/... anyway.

> However, %_datadir is a per-package command line parameter to rpmbuild,
> and which can be overridden at any time (--define is documented, cf.
> rpmbuild --help). 

Which is a moot point, since many other macros can be customised via
rpmbuild or a custom default RPM config, too. Just redefine %_libdir and
get package which drops DSOs into a directory not in standard run-time
linker's search path.
 
> You are simply ignoring this fact, and instead are blindly relying on
> every build run to use the same parameter (here defaults as implicitly
> provided by rpm).

Yeah, right, we do build for the environment known as Fedora Core.

Go and build half of Fedora Core/Extras with a relocated %_datadir and
have fun with the wreckage. In the context of FC/FE, %_datadir must be
%_prefix/share for the entire set of packages. Or else we would need to
convert many package dependencies into path/file dependencies.
 
> Anyway, apparently we do not share the same view, this issue is not
> worth further fretting over, so I'll keep my face shut and leave it up
> to you to shoot yourself into the foot ;-)

In this case, /usr/share vs. %_datadir is not a blocker criterion
anyway.