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.
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.
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
packaging@lists.fedoraproject.org
-
Matthew Miller -
Michael A. Peters -
Ralf Corsepius