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

[Ralf Corsepius]

On Mon, 2005-04-25 at 17:44 +0200, Michael Schwendt wrote:
> 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
The is the place setting the default value.

> > > 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. 

I don't hope this should be read as "we are supposed to be blind and
narrow minded" ;-)

> > 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.
True.

Ask yourself why __xxx macros using a hard-coded default exit.

>  Just redefine %_libdir and
> get package which drops DSOs into a directory not in standard run-time
> linker's search path.

... just bugs.

... not worth mentioning the borkenness of the brp-* stuff, the broken'
perl(xxx) deps, and ...

> > 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.
... bugs.

> Or else we would need to
> convert many package dependencies into path/file dependencies.
You've got the point - This is what this actually is about:
Package vs. file dependencies.

I've repeatedly said that I consider file dependencies to be much
superior to package dependencies.

Ralf