FESCo approved this in https://pagure.io/fesco/issue/3473:
> AGREED: /nix top-level directory may be used exclusively for Nix
> runtime and package store. It shall not be part of the filesystem
> package, but packages are allowed to create it. (+6, 1, -0)
The restriction mentioned is likely tied to the build scripts, not the scriptlets.
In that case it is a duplicate with the text after it, so I removed it entirely.
Link to this document:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md
for descibing the correct way to manipulate the compiler flags.
Set the requirement to:
"SHOULD avoid editing the 'CFLAGS' etc. environment variables by hand".
The goal of this change is to encourage people to start using the standard
set of macros we have, instead of inventing their own ways to edit
the CFLAGS / CXXFLAGS etc. enviromental variables.
This is a part of this Fedora Change for F43:
https://fedoraproject.org/wiki/Changes/Package-specific_RPM_Macros_For_Build_Flags
which introduced a set of macros for adding flags at the end of the default set,
which should obsolete any other way people invented to edit the content
of the CFLAGS / CXXFLAGS etc. enviromental variables.
The main advantages are that it is propagated to all calls of the %set_build_flags macro,
in every section, in the whole SPECfile. (instead of just the lines after
the "export CFLAGS" etc. call until the end of the current section)
Also, it is much more auditable.
qt-devel is for qt4 only and is no longer used.
Nowdays the qt linguist tools get pulled in by dependencies whenever the kfX-rpm-macros or qtX-qttools-devel is installed.
But, for those cases where neither of those packages are added, and the Qt Linguist tool chain is needed, we should require qt6-linguist.
Signed-off-by: Troy Dawson <tdawson@redhat.com>
This reverts commit 35d89f0f3f.
Expanding `%{_bindir}` does not help with deciding, where some specific
tool comes from. Paths must always be taken with care.
rpm uses the location listed in %files as the canonical location of a file.
This is the location that must be used in Requires to refer to files.
(In other words, even though /bin is a symlink to /usr/bin, and /bin/foo
is really /usr/sbin/foo in the file system, if the package has /bin/foo
in %files, Requires:/usr/bin/foo is not going to work.)
When UsrMove was implemented 10+ years ago, the real locations in the file
system were changed from /[b]bin/* to /usr/[b]bin/*, but as a compatibility
measure, a packaging rule was introduced where the location reported in %files
was supposed to stay unchanged, so that other packages which used file
dependencies wouldn't need to be updated. The rule means that the packager needs
to figure out where the file was located "historically" and make %files conform
to that. This obviously made the transition easier, but I think it's time to
retire this rule. In fact, I think the rule has been mostly forgotten, because
it doesn't seem to be widely known or followed and many important packages
violate it (for example util-linux, systemd).
In fact the rule now it makes the life of packagers harder, because they cannot
just check where the file is located, they need to do the dance where they check
the canonical location of the file:
rpm -ql $(rpm -qf /usr/sbin/ifconfig)|grep sbin/ifconfig
We can make packaging easier by removing the rule. It's possible that some
packages using file dependencies will need to be adjusted, but it's probably not
many and it should be simple to fix them.
Once the rule is removed from Packaging Guidelines, we can simplify packages
that still take the extra steps to followed the rule to just list files normally
in %files.
I noticed this rule when preparing for the unification of /usr/bin and /usr/sbin
(https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin). It's not
strictly necessary, but I think that if we simplify file locations, it's good
to get rid of this old complex rule too.
When rpmautospec is used, %{dist} is not directly visible to the maintainer,
so adjust the text to use ".fcNN" instead, which is what the maintainer will
see when %autorelease is expanded. With this adjustment, the text should apply
to both %autorelease and traditional release handling.
Also, add a note to point the maintainer to 'rpmautospec calculate-release'.
Change '<=' to '<' in one more place: '<=' is just confusing, because equality
generally cannot be achieved because of %{dist} and the operator was changed
to '<' in most places, but apparently forgotten here.
Addresses https://pagure.io/fedora-infra/rpmautospec/issue/225.
See https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
The general approach is the the previous recommendations are described
with "may" and moved to the end or to a separate page. Use of
rpmautospec is shown briefly, but with enough information for normal
packaging workflows. Links are provided to the rpmautospec docs in
case packagers need more information.
The text is inverted, to list the allowed uses first, and then to exclude the
unwanted ones.
The text didn't mention the case where one package has an explicit
Provides:/some/path and another package uses
Requires|Recommends|Suggests:/some/path. Those explicit Provides are included in
the primary metadata and can be used with no problem and they are sometimes
useful to coordinate functionality between packages.
Also, with dnf5 the split between "primary" and "filelists" metadata matters
again, and the latter is not dowloaded by default. So reword the explanation
a bit to discourage packagers from using it.
The rule is extended to also cover directories. I suspect that the omission was
just clumsy language and not intentional.
