> In general, we should stick to upstream packaging unless it is clearly
> broken or there is a compelling reason to deviate. In this case, if an
> application can't find , then it would seem to have a
> buggy build system, and we should fix the problem there.
The qt-gstreamer package doesn't bui
David Craven writes:
>> What is the reason for this change? Would it be appropriate to submit a
>> bug report upstream to add this to their "make install"?
>
> The reason is because applications may contain #include ,
> but gstconfig.h was moved to the lib directory because it contains "platform
> What is the reason for this change? Would it be appropriate to submit a
> bug report upstream to add this to their "make install"?
The reason is because applications may contain #include ,
but gstconfig.h was moved to the lib directory because it contains "platform
specific information".
What
David Craven writes:
> * gnu/packages/gstreamer.scm (gstreamer)[arguments]: Add symlink-gstconfig.h
> phase.
What is the reason for this change? Would it be appropriate to submit a
bug report upstream to add this to their "make install"?
Mark
> ---
> gnu/packages/gstreamer.scm
* gnu/packages/gstreamer.scm (gstreamer)[arguments]: Add symlink-gstconfig.h
phase.
---
gnu/packages/gstreamer.scm | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index bd99880..54919cd 100644
--- a/gnu/packa
