[Fedora-packaging] %doc doesn't seem to use _defaultdocdir definition [solved]

[Daniel Letai]

Far as I can tell the solutions are very similar - I used a suffix defined
in the preamble, and modules to set PATH, LD_LIBRARY_PATH etc, SCL seems to
use a prefix defined on the command line and requires implementing the
enable script on a per package basis, but other than that the solutions
seem identical.

Had I known of scl in advance, I'd probably use it. As it is, I prefer
modules for the built in facilities for manipulating environment variables

I do have a small snug though - .I use "provides" tags without version as
in:

%package c++
Summary: C++ support for GCC
Group: Development/Languages
Requires: gcc%{gcc_suffix} = %{version}-%{release}
Requires: libstdc++%{gcc_suffix} = %{version}-%{release}
Requires: libstdc++%{gcc_suffix}-devel = %{version}-%{release}
Autoreq: true
Provides: gcc-c++

and gcc_suffix can be 474/484/492/etc.
This causes a conflict with binutils;
rpm -q --conflicts binutils
gcc-c++ < 4.0.0

and if trying yum install:
--> Processing Conflict: binutils-2.20.51.0.2-5.42.el6.x86_64 conflicts
gcc-c++ < 4.0.0
--> Finished Dependency Resolution
Error: binutils conflicts with gcc484-c++-4.8.4-1.el6.x86_64

It seems to me from reading about the conflicts tag that this behavior is
wrong. Without version in the provides, it should be assumed to be a
virtual package, so conflict based on version should not happen.

Am I wrong and this is the expected behavior?

I don't know if the correct solution is to provide a version in the
provides: tag (will it affect yum update, i.e. cause yum to replace gcc-c++
with gcc484-c++ even though there is no file conflict) or to force
installation with nodeps, or something else.


On Thu, Apr 9, 2015 at 1:26 PM, Mat Booth <fedora at matbooth.co.uk> wrote:

> On 9 April 2015 at 10:56, Daniel Letai <dani at letai.org.il> wrote:
>
>> Thanks, It now works
>> I also had to move it prior to the 1st %description tag.
>>
>> BTW, I have built a gcc toolchain rpms (gmp, mpfr, mpc, cloog, isl, osl
>> and gcc - each in it's own rpm) using environment modules to allow multiple
>> version co-existence.
>>
>> It works well enough internally in our own production environment, I'm
>> wondering if anyone else might have use of such an environment.
>>
>> The %doc was the last issue.
>>
>>
> It sounds like you have very nearly re-invented "software collections"
> because it does something similar: https://www.softwarecollections.org/en/
>
>
>
>
>>
>> On 04/09/2015 11:34 AM, Ville Skyttä wrote:
>>
>>> On Thu, Apr 9, 2015 at 10:13 AM, Daniel Letai <dani at letai.org.il> wrote:
>>>
>>>> $ cat sample_rpm.spec
>>>>
>>> [...]
>>>
>>>> global _defaultdocdir /opt/sample_rpm/share/doc
>>>>
>>> Try %global instead of global.
>>> --
>>> packaging mailing list
>>> packaging at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/packaging
>>>
>>
>> --
>> packaging mailing list
>> packaging at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/packaging
>>
>> --
>> <https://admin.fedoraproject.org/mailman/listinfo/packaging>
>> Mat Booth
>> <https://admin.fedoraproject.org/mailman/listinfo/packaging>
>> http://fedoraproject.org/get-fedora
>>
>
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20150411/aecdbdb8/attachment.html>