On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
- A packager rebuilds packages from Fedora dist-git in a Copr repo, what will
be the value of the build tag? How will the Copr build sort over the official Fedora builds? (This is essentially the same question but the answer might differ.)
Similar as above, the questions would be how does it work now, do we want a change or do we want to keep the current setup?
Examples from before the Python 3.11 side tag was merged.
Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10) Python 3.11 copr: python3-tomli-2.0.1-2.fc37 (built with Python 3.11)
The NEVRs are identical. Other builds in the Python 3.11 copr install the 3.11 build.
Now when we managed to not pick up a certain bump:
Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10) Python 3.11 copr: python3-tomli-2.0.1-1.fc37 (built with Python 3.11)
The rawhide's NEVR is higher. Other builds in the Python 3.11 copr install try to install the 3.10 build and that conflicts with other stuff in the copr and the dependency resolution fails.
We certainly don't want to regress in that regard.
On Thursday, 23 June 2022 at 15:01, Miro Hrončok wrote:
On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
- A packager rebuilds packages from Fedora dist-git in a Copr repo, what will
be the value of the build tag? How will the Copr build sort over the official Fedora builds? (This is essentially the same question but the answer might differ.)
Similar as above, the questions would be how does it work now, do we want a change or do we want to keep the current setup?
Examples from before the Python 3.11 side tag was merged.
Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10) Python 3.11 copr: python3-tomli-2.0.1-2.fc37 (built with Python 3.11)
The NEVRs are identical. Other builds in the Python 3.11 copr install the 3.11 build.
Now when we managed to not pick up a certain bump:
Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10) Python 3.11 copr: python3-tomli-2.0.1-1.fc37 (built with Python 3.11)
The rawhide's NEVR is higher. Other builds in the Python 3.11 copr install try to install the 3.10 build and that conflicts with other stuff in the copr and the dependency resolution fails.
We certainly don't want to regress in that regard.
You can build almost anything in COPR and with random NEVRA. Accommodating what you described above would be nice to have, but should definitely not be a requirement. Adding build ID would not help here, either, as they will be different between different build systems.
COPR builds have different buildhost and are signed with a different signature. You cannot expect two packages with identical NEVRA but different buildhost and signature to have identical dependencies and contents.
Regards, Dominik
On 24. 06. 22 9:30, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 23 June 2022 at 15:01, Miro Hrončok wrote:
On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
- A packager rebuilds packages from Fedora dist-git in a Copr repo, what will
be the value of the build tag? How will the Copr build sort over the official Fedora builds? (This is essentially the same question but the answer might differ.)
Similar as above, the questions would be how does it work now, do we want a change or do we want to keep the current setup?
Examples from before the Python 3.11 side tag was merged.
Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10) Python 3.11 copr: python3-tomli-2.0.1-2.fc37 (built with Python 3.11)
The NEVRs are identical. Other builds in the Python 3.11 copr install the 3.11 build.
Now when we managed to not pick up a certain bump:
Fedora rawhide: python3-tomli-2.0.1-2.fc37 (built with Python 3.10) Python 3.11 copr: python3-tomli-2.0.1-1.fc37 (built with Python 3.11)
The rawhide's NEVR is higher. Other builds in the Python 3.11 copr install try to install the 3.10 build and that conflicts with other stuff in the copr and the dependency resolution fails.
We certainly don't want to regress in that regard.
You can build almost anything in COPR and with random NEVRA. Accommodating what you described above would be nice to have, but should definitely not be a requirement. Adding build ID would not help here, either, as they will be different between different build systems.
No, adding build ID would break this.
COPR builds have different buildhost and are signed with a different signature. You cannot expect two packages with identical NEVRA but different buildhost and signature to have identical dependencies and contents.
I don't.
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Miro Hrončok