Bug 1563789 - python3-rpm-macros should require python3
Summary: python3-rpm-macros should require python3
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: python-rpm-macros
Version: 30
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-04 17:20 UTC by yucef sourani
Modified: 2019-07-23 13:19 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-23 13:19:21 UTC
Type: Bug


Attachments (Terms of Use)

Description yucef sourani 2018-04-04 17:20:06 UTC
Description of problem:
i have repository on copr,
https://copr.fedorainfracloud.org/coprs/youssefmsourani/gvrecord/

in fedora 28 Chroot copr packaging pygnomescast with wrong paths but on local system (rpmbuild) Everything is good .
https://imgur.com/a/N2Ns7



SPEC File:
https://gist.github.com/yucefsourani/dfe5c82f46e593523a5a0ee23d6253fc

Comment 1 Pavel Raiskup 2018-04-05 05:04:54 UTC
Thanks for the report,

(In reply to yucef sourani from comment #0)
> Description of problem:
> i have repository on copr,
> https://copr.fedorainfracloud.org/coprs/youssefmsourani/gvrecord/
> 
> in fedora 28 Chroot copr packaging pygnomescast with wrong paths but on
> local system (rpmbuild) Everything is good .
> https://imgur.com/a/N2Ns7

but this unfortunately doesn't specify enough what is the problem with
your package.

> SPEC File:
> https://gist.github.com/yucefsourani/dfe5c82f46e593523a5a0ee23d6253fc

That spec file is several times concatenated  in one file:

    cat *.spec | grep %package
    %package -n pygnomescast
    %package -n pygnomescast
    %package -n pygnomescast
    %package -n pygnomescast
    %package -n pygnomescast

Anyway, this certainly isn't bug in 'Product: Copr', but rather packaging
issue, I'm closing this since bugzilla is not proper place to ask for
help with packaging.  If you want, feel free to discuss more here but
I would encourage you to write an email to devel@lists.fedoraproject.org
mailing list.

Comment 2 Pavel Raiskup 2018-04-05 05:16:56 UTC
yucef sourani, see:
https://fedoraproject.org/wiki/Packaging:Python

The 'BuildRequires: python3-devel' is missing.

Comment 3 Miroslav Suchý 2018-04-05 11:45:38 UTC
This is actually bug. And you can reproduce it when you
wget https://copr-be.cloud.fedoraproject.org/results/youssefmsourani/gvrecord/fedora-28-x86_64/00736956-gvrecord/gvrecord-0.3-2.fc28.src.rpm
mock -r fedora-28-x86_64 gvrecord-0.3-2.fc28.src.rpm

Or more easily:

mock -r fedora-28-x86_64 install python3-rpm-macros
mock -r fedora-28-x86_64 shell 
  [root@dri<mock-chroot>//]#rpm --eval '%{python3_sitelib}'
  sh: /usr/bin/python3: No such file or directory


It can be easily workarounded in this case by:

BuildRequires: python3-devel

But I suppose that python3-rpm-macros should require python3.

Comment 4 Pavel Raiskup 2018-04-05 12:03:44 UTC
According to https://github.com/rpm-software-management/rpm/issues/424
the macros should really work IOM; but guidelines say that python3-devel
has to be in BuildRequires, so .. dunno.

Comment 5 yucef sourani 2018-04-05 12:32:15 UTC
(In reply to Pavel Raiskup from comment #1)
> Thanks for the report,
> 
> (In reply to yucef sourani from comment #0)
> > Description of problem:
> > i have repository on copr,
> > https://copr.fedorainfracloud.org/coprs/youssefmsourani/gvrecord/
> > 
> > in fedora 28 Chroot copr packaging pygnomescast with wrong paths but on
> > local system (rpmbuild) Everything is good .
> > https://imgur.com/a/N2Ns7
> 
> but this unfortunately doesn't specify enough what is the problem with
> your package.
> 
> > SPEC File:
> > https://gist.github.com/yucefsourani/dfe5c82f46e593523a5a0ee23d6253fc
> 
> That spec file is several times concatenated  in one file:
> 
>     cat *.spec | grep %package
>     %package -n pygnomescast
>     %package -n pygnomescast
>     %package -n pygnomescast
>     %package -n pygnomescast
>     %package -n pygnomescast
> 
> Anyway, this certainly isn't bug in 'Product: Copr', but rather packaging
> issue, I'm closing this since bugzilla is not proper place to ask for
> help with packaging.  If you want, feel free to discuss more here but
> I would encourage you to write an email to devel@lists.fedoraproject.org
> mailing list.


I know how to packaging,It is one file but I do not know why this is repeat on GithubGist ,And I do not think I need a python3-devel package because I did not use "python setup" "python build" ... 

Also the problem is only in Fedora 28 Chroot and Fedora rawhide Chroot .

Thank you for your interest .

(sorry for my english and again Thank you)

Comment 6 yucef sourani 2018-04-05 12:36:24 UTC
(In reply to Miroslav Suchý from comment #3)
> This is actually bug. And you can reproduce it when you
> wget
> https://copr-be.cloud.fedoraproject.org/results/youssefmsourani/gvrecord/
> fedora-28-x86_64/00736956-gvrecord/gvrecord-0.3-2.fc28.src.rpm
> mock -r fedora-28-x86_64 gvrecord-0.3-2.fc28.src.rpm
> 
> Or more easily:
> 
> mock -r fedora-28-x86_64 install python3-rpm-macros
> mock -r fedora-28-x86_64 shell 
>   [root@dri<mock-chroot>//]#rpm --eval '%{python3_sitelib}'
>   sh: /usr/bin/python3: No such file or directory
> 
> 
> It can be easily workarounded in this case by:
> 
> BuildRequires: python3-devel
> 
> But I suppose that python3-rpm-macros should require python3.

I've added BuildRequires: python3 and have solved the problem .
I will later try to replace python3 with python3-devel .
thank you.

Comment 7 Ben Cotton 2019-05-02 21:34:54 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Pavel Raiskup 2019-05-16 12:50:24 UTC
$ rpm -qR python3-rpm-macros python-srpm-macros
python-srpm-macros >= 3-38
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
$ rpm -q python3-rpm-macros
python3-rpm-macros-3-42.fc30.noarch

Comment 9 Miro Hrončok 2019-06-18 21:47:51 UTC
The macros don't work without python3, but just BRing the macros is non a supported use case.

Also, if you redefine %__python3 to /usr/bin/pypy3 (however absurd, still possible), you might need to require pypy3 as well.

This package contains the macro definitions (information). If you actually want to use them in spec, you should BR python3-devel.

(This bugzilla was long ignored by me, as I was not a maintainer of this package.)

Can we close this as WONTFIX?

Comment 10 Pavel Raiskup 2019-06-19 08:12:32 UTC
(In reply to Miro Hrončok from comment #9)
> The macros don't work without python3, but just BRing the macros is non a
> supported use case.

The package isn't (now?) installed in minimal buildroot, so I can accept this
is not supported use-case.

Though....  it sounds really weird and confusing.  Usually providing separate
sub-package has some benefits;  what are the benefits in case of
python3-rpm-macros when the *one and only one* package which should ever
depend on it is python3-devel?  Shouldn't python3-devel be merged with
pytho3-rpm-macros?

What is wrong on depending on python3-devel (or python3) from
python3-srpm-macros?

> Also, if you redefine %__python3 to /usr/bin/pypy3 (however absurd, stil
> possible), you might need to require pypy3 as well.

I might be selfish Fedora user :-), but I only mind supported default
use-cases.

> This package contains the macro definitions (information). If you actually
> want to use them in spec, you should BR python3-devel.

Agreed, don't know why I thought those macros are available by default, and
python policy says clearly that python3-devel is mandatory.

> Can we close this as WONTFIX?

If you find the above invalid, feel free.  I just don't think it is correct to
install macros which fail by default, less severe (doesn't affect builds)
issue is e.g. https://github.com/rpm-software-management/rpm/issues/424

Comment 11 Pavel Raiskup 2019-06-19 08:20:07 UTC
FWIW, from: https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz

$ grep -r ^BuildRequires | grep -e python2-rpm-macros -e python3-rpm-macros -e python-rpm-macros | cut -d: -f1 | sort | uniq  | wc -l
38

Comment 12 Miro Hrončok 2019-06-19 09:07:25 UTC
Actually if I wanted to build for pypy3 with those macros, depending on python3 would drag in unnecessary python3.

I still deem this invalid use case. I see your point, but I don't think it needs to be changed. Leaving this open for more discussion, will share on python-devel.

Comment 14 Miroslav Suchý 2019-06-20 09:43:36 UTC
Hmm... Dynamic Build Requires? Although it would be clumsy to use it with the current implementation.

Comment 15 Miro Hrončok 2019-06-20 12:41:40 UTC
Dynamic Build Requires will be handled separately. Already hacking on that in https://github.com/hroncok/pyproject_dynamicbrs


Note You need to log in before you can comment on or make changes to this bug.