Building src.rpm's outside of mock/mach

[Michael A. Peters]

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.

[Matthew Miller]

On Sat, Jul 16, 2005 at 12:45:19AM -0700, Michael A. Peters wrote:
>  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. 
I think the configure switch is the best way -- it makes the choice of what
to package explicit.

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.

[Ralf Corsepius]

On Sat, 2005-07-16 at 00:45 -0700, Michael A. Peters wrote:

>  Is it a packaging error if a src.rpm can only be expected to
> reliably
>  build inside mock/mach? 
IMO, yes, definitely - Package building/re-building must
be
deterministically reproduce the same results in both chroot'ed and
non-chroot'ed environments.

>  If it is a packaging error, what would be the best course of action?
IMO, if a package can't be rebuilt in a user environment it qualifies as
broken and "not ready for release".

>  Some solutions include manually installing what you DO want to
> package 
That would be a packager's hack/resort to work around a broken 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. 
Yes, this would be an approach upstream
could choose to fix such issues.

Ralf