packaging February 2023

packaging@lists.fedoraproject.org

11 participants
6 discussions

license of the binary policy
by Jilayne Lovejoy 25 Mar '24

25 Mar '24

Hi Fedora legal and packaging, I'm cross-posting this, as I think it's relevant to both groups. The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelin… ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask." As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following: 1) how do you (package maintainers) interpret this policy in practice? 2) what further information/documentation about this policy would be helpful? 3) should this policy be different, and if so, how? 4) any other related thoughts or observations Thanks! Jilayne

12 39

Automatic virtual provides for RPM macros?
by Miro Hrončok 10 Mar '23

10 Mar '23

Hello, today at Nest, somebody said "unfortunately, there is no way to tell what package to install to get a particular RPM macro". I think that having an RPM provides generator for "rpm-macro(__python3)" or similar should be a fairly simple exercise. Would you folks consider that useful? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 4

Packaging python3-*-devel subpackages
by Miro Hrončok 18 Feb '23

18 Feb '23

Hello Pythonistats and packaging folks. Tomáš (CCed) approached me today with an interesting question. A Python package he is packaging into RPM (python3-rapidfuzz) installs some development files (.h and .pxd). Tomáš queried upstream about those files to figure out if they should be installed or if they are only needed to build the package itself. Upstream responded: > rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which allows users > to write their own similarity metrics in C/C++/Cython, which can be called by > rapidfuzz in a more performant way through this C-API. > For this reason the header file should be part of the installation as well. OK, we want to ship them. Our packaging guidelines however say: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages > Specifically, -devel packages must be used to contain files which are > intended solely for development or needed only at build-time. This is done to > minimize the install footprint for users. There are some types of files which > almost always belong in a -devel package: > - Header files... So from our guidelines perspective, the files would go to python3-rapidfuzz-devel. The way we packaged Python in 201x, this would be the end of it. However, in this decade with automatic Python BuildRequires, we could easily end up in this situation: 1. a Python package lists rapidfuzz as a build requirement 2. %pyproject_buildrequires generates a dependency on python3dist(rapidfuzz) 3. only python3-rapidfuzz is pulled 4. %build wants to use rapidfuzz.h 5. packager needs to manually BuildRequire python3-rapidfuzz-devel To avoid (5), my suggestion was to add the following requirement to python3-rapidfuzz: Requires: (python3-rapidfuzz-devel%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} if python3-devel) That way, application packages that pull in pytohn3-rapidfuzz as a runtime dependency won't get it (we are minimizing the install footprint for users), but users who build stuff (including RPM packages) will get it (we make automatically generated dependencies work as intended). (Of course, users who have python3-devel installed for reasons other than rapidfuxx will still get the files, but the assumption here is that users who install -devel packages intent to /generally/ build stuff.) Is that a good suggestion? And if so, should it be a general recommendation for such cases? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

6 5

Trying to set up a clean upgrade path for celestia
by Mattia Verga 15 Feb '23

15 Feb '23

I'm trying to set up a clean upgrade path for celestia. Previously there was a monolithic 'celestia' package with everything inside it, now there will be a separate 'celestia-data' package (from a different source repository), while the former 'celestia' package will be splitted in 'celestia-common', 'celestia-gtk' and 'celestia-qt'. The plan is that when a user upgrade from pre 1.7, it should end up with 'celestia-gtk' as default interface, which requires both 'celestia-common' and 'celestia-data'. I have set the 'celestia' specfile as follows: %package common Obsoletes: %{name} < 1.6.3 %package gtk Requires: %{name}-common%{?_isa} = %{version}-%{release} Provides: %{name} = %{version}-%{release} I have prepared a build at https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/5517618/ When running an upgrade coming from pre 1.7, I get: # dnf upgrade celestia --refresh ... ========================================================================================== Package Arch Version Repository Size ========================================================================================== Installing: celestia-common x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 2.0 M sostituisce celestia.x86_64 1.6.2-0.8.beta3.fc37 Installazione dipendenze: celestia-data noarch 1.7.0~20230223ffc806d-1.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 281 M celestia-gtk x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 76 k ... Errore: Errore test di transazione: il file /usr/share/celestia/fonts dell'installazione di celestia-common-1.7.0~202302239c1c4e4-0.3.fc37.x86_64 entra in conflitto con il file del pacchetto celestia-1.6.2-0.8.beta3.fc37.x86_64 So, dnf correctly finds that celestia-common obsoletes celestia, still it complains about conflicting files.... ? Have I set up something wrong?

4 5

Any change we can get a github action that triggers downstream packaging on release?
by Sorin Sbarnea 13 Feb '23

13 Feb '23

I recently added a reusable github action to ansible-lint release pipeline that makes a pull-request on homebrew recipe that bumps its version. https://github.com/ansible/ansible-lint/pull/2982/files This worked perfectly from the first attempt and now we do know that we don't need to wait for someone to remember to update ansible-lint recipe. While we do have a pipeline that uses packit service to test that rpm packaging is not broken from incoming pull requests, we do not have any automated way to trigger RPM packaging an update for fedora when we release a new version. Would it be possible to get a similar action that we can chain on our release pipeline? -- Cheers, Sorin Sbarnea Ansible DevTools Team Lead, Red Hat

2 1

Where are the old package versions?
by Travis Sidelinger 02 Feb '23

02 Feb '23

Packagers, Recently I needed to test to see if the new version of Wine-8.0rc4 broke my games. "dnf downgrade wine" should do the trick. Wait... # dnf list --showduplicates wine | column -t Available Packages wine.i686 7.2-1.fc36 fedora wine.x86_64 7.2-1.fc36 fedora wine.i686 8.0-0.rc4.1.fc36 updates wine.x86_64 8.0-0.rc4.1.fc36 updates Wine-7.2 is much older. But where did the previous versions (7.22) go? Why are old versions being removed from the repo? Is there another repo we can use to access all package versions? -Travis

6 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2023