#915 Modernize python spec file example
Closed 2 years ago by zbyszek. Opened 2 years ago by zbyszek.
zbyszek/packaging-committee python-brs-and-description  into  master

@@ -9,18 +9,21 @@ 

  URL:            https://pypi.python.org/pypi/example

  Source0:        %{pypi_source}

  

+ BuildRequires:  python3-devel

+ #BuildRequires: ...

  BuildArch:      noarch

  

- %description

- An python module which provides a convenient example.

+ %global _description %{expand:

+ A python module which provides a convenient example. This is the

+ rest of of the description that provides more details.}

+ 

+ %description %_description

  

  %package -n python3-%{srcname}

  Summary:        %{summary}

- BuildRequires:  python3-devel

This is a matter of style isn't it?

  %{?python_provide:%python_provide python3-%{srcname}}

  

- %description -n python3-%{srcname}

- An python module which provides a convenient example.

+ %description -n python3-%{srcname} %_description

  

  %prep

  %autosetup -n %{srcname}-%{version}

@@ -51,16 +51,17 @@ 

  

  BuildArch:      noarch

  

- %description

- An python module which provides a convenient example.

+ %global _description %{expand:

+ A python module which provides a convenient example.}

+ 

+ %description %_description

  

  %package -n python2-%{srcname}

  Summary:        %{summary}

  BuildRequires:  python2-devel

  %{?python_provide:%python_provide python2-%{srcname}}

  

- %description -n python2-%{srcname}

- An python module which provides a convenient example.

+ %description -n python2-%{srcname} %_description

  

  

  %package -n python3-%{srcname}
@@ -68,8 +69,7 @@ 

  BuildRequires:  python3-devel

  %{?python_provide:%python_provide python3-%{srcname}}

  

- %description -n python3-%{srcname}

- An python module which provides a convenient example.

+ %description -n python3-%{srcname} %_description

  

  

  %prep
@@ -210,10 +210,10 @@ 

  

  BuildArch:      noarch

  

+ %global _description %{expand:

+ A python module which provides a convenient example.}

  

- %description

- An python module which provides a convenient example.

- 

+ %description %_description

  

  %if %{with python2}

  %package -n python2-%{srcname}
@@ -221,8 +221,7 @@ 

  BuildRequires:  python2-devel

  %{?python_provide:%python_provide python2-%{srcname}}

  

- %description -n python2-%{srcname}

- An python module which provides a convenient example.

+ %description -n python2-%{srcname} %_description

  %endif

  

  
@@ -231,8 +230,7 @@ 

  BuildRequires:  python3-devel

  %{?python_provide:%python_provide python3-%{srcname}}

  

- %description -n python3-%{srcname}

- An python module which provides a convenient example.

+ %description -n python3-%{srcname} %_description

  

  

  %prep

no initial comment

I'd rather get https://pagure.io/packaging-committee/pull-request/903 in first.

They don't conflict.

This is a matter of style isn't it?

rpmbuild doesn't care, so it's certainly a matter of style only. Nevertheless, I think the change is warranted: most python packages now build python3, and this means that the BR "for the python3 subpackage" are really BRs for the whole package. And if we suggest to people to put BR:python3-devel there, they'll most likely put other BRs there, so there'll be BR:gcc, BR:some-other-tool there. I think it's better to the BRs at the top.

Can I get some kind of decision here? Yay or nay on each of the two paches. This isn't important enough to keep open forever.

python: recommend %{expand:} trick to avoid duplicating description - +1 from me
python: move BuildRequires to the top - I abstain. I like them where they are but I don't mind them at the top

Metadata Update from @churchyard:
- Pull-request tagged with: meeting

2 years ago

I know it is bikeshedding, but I prefer subpackage-specific buildrequires in subpackage section (like python3-devel) and things like gcc on top. But that's just my preference.

Using expand trick is definitely +1.

prefer subpackage-specific buildrequires in subpackage section (like python3-devel) and things like gcc on top.

In general, I'd agree. But in python packages we have the unusual situation that the "main" binary package name is always different from the srpm name. Splitting the BR in two would mean that there would be two BR blocks, even though there's (often) just one binary package.

Metadata Update from @churchyard:
- Pull-request untagged with: meeting
- Request assigned

2 years ago

Pull-Request has been closed by zbyszek

2 years ago