I'm all for building rpm's inside mach/mock because it avoids unintended
dependencies (IE you build sox outside of mock, and have lame-devel and
libmad-devel on your system, the resulting sox rpm will be linked
against them)
But what about cases where building outside of mock results in a build
error, should that be considered a packaging error?
The question came about as result of working on a gstreamer-plugins
add-on package.
If make install is used in the spec file, it works fine when built
inside mock because the necessary devel packages for core plugins are
not there.
But when the same src.rpm is rebuilt on a user system, it may result in
a build error because make install will potentially build plugins that
aren't intended to be packaged.
Is it a packaging error if a src.rpm can only be expected to reliably
build inside mock/mach?
If it is a packaging error, what would be the best course of action?
Some solutions include manually installing what you DO want to package
(what I have been doing), perhaps a bunch of configure switches telling
configure not to build all of the plugins you don't intend to package,
or telling rpm to ignore unpackaged files.