I am doing package review and there is a summary that ends with a dot.
I am sure that for long time we had in packaging guidelines that summary should be max 80 characters and should not end
with dot.
I cannot find the reference to the dot now
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_summary_and_des…
Was this intentional change?
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
The packaging guidelines currently allow file dependencies in /etc,
/usr/bin, and /usr/sbin to be used in spec files. However, this can
pose a problem for Fedora Flatpak builds, where an ever-growing number
of packages are being built for flatpaks in /app which breaks such file
dependencies.
(A separate problem is posed by the use of installation path macros in
file dependencies, but that is already disallowed; see further
discussion in https://pagure.io/packaging-committee/pull-request/1346 )
Regarding /usr/bin and /usr/sbin file dependencies, generally the
intention is "require whichever package that installs this command in
$PATH". In such a case, it doesn't really matter if it's in /usr/bin
(for normal RPM builds, or for packages in the flatpak runtime, or for
flatpak buildroot-only dependencies) or in /app/bin (from packages
built for flatpaks). While the package name providing that command
could be used, package contents can vary over time, and maintainers
want to avoid having to track that.
Common examples are /usr/bin/groff (groff-base) and /usr/bin/pod2man
(perl-podlators), both of which are now built in /app to support perl
for flatpak apps.
Option 1 would be for either rpm or redhat-rpm-config to generate e.g.
cmd(foo) virtual provides for /usr/bin/foo or /usr/sbin/foo (and for
flatpaks, also for /app/bin/foo or /app/sbin/foo). Packages would then
[B]R: cmd(foo), and (eventually) file dependencies in /usr could be
dropped entirely. (The "cmd" name is just an example and could of
course be changed.)
The major disadvantage of this approach is the implementation time
involved. Even if it were to be implemented prior to the F41 mass
rebuild, it would not be usable across all stable Fedora versions until
the middle of F43 development (after F40 EOL), and wouldn't be
compatible with EPEL for a long time (although that could be shortened
somewhat if it gets into c10s before the last mass rebuild). It would
also create a lot more virtual provides, but would be a big step closer
to dropping file dependencies entirely.
Option 2 would be to boolean dependencies, e.g.:
[Build]Requires: (/usr/bin/foo or /app/bin/foo)
This would avoid the implementation delay but is much more verbose.
Thoughts?
--
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
I'm currently packaging indi-3rdparty-libraries by stripping out sources from binary SDKs provided upstream.
That means only a few devices are actually supported to work in Fedora.
I'm now getting interest in adding support for some cameras I'm about to buy, probably from Player One. Fedora Packaging Guidelines says it's ok to have binary firmware packages when this is required to have hardware function properly. indi-3rdparty includes [1] the Player One SDK to make those cameras work.
Now, I'm a bit confused: are those SDK binary files considered as firmware to make hardware function properly? The license under which they are distributed is MIT, so it would be ok...
[1] https://github.com/indilib/indi-3rdparty/tree/master/libplayerone
