license of the binary policy
by Jilayne Lovejoy
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/LicensingGuidel...
) 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
1 month
Automatic virtual provides for RPM macros?
by Miro Hrončok
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
1 year, 1 month
Packaging python3-*-devel subpackages
by Miro Hrončok
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
1 year, 2 months
Trying to set up a clean upgrade path for celestia
by Mattia Verga
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?
1 year, 2 months
Any change we can get a github action that triggers downstream packaging on release?
by Sorin Sbarnea
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
1 year, 2 months
Where are the old package versions?
by Travis Sidelinger
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
1 year, 2 months
