Ideally, the NEVRA would indicate the vendor via the `%_dist` suffix. Fedora,
ELN, RHEL, SuSE mostly use unique suffixes. Of course this doesn't help when
derivates rebuild using the same suffix. But I think with this, we're getting
into the territory of SBOMs. Any reasonable SBOM should be enou
Perhaps I shouldn't overload the issue but the other big problem I see with rpm
building is the source of packages. All that `rpm` does is confirm the packages
are installed for building `BuildRequires:` or for installing `Requires:` but a
package name on its own is not helpful as many people ma
Ah, OK, thanks for the clarification.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2654#discussioncomment-8721879
You are receiving this because you are subscribed to this thread.
Message ID:
___
Something like this can't really be a macro configurable between such
wildly differing purposes, especially when callers almost certainly expect the
traditional default behavior anyway. I can't see anybody missing this.
Besides nuking an apparently unnecessary feature and weird logic (how many
CPU count we try to hide behind `${RPM_BUILD_NCPUS}`, eg %_smp_mflags returns
that literally, so it only evaluates to a number during the actual script
execution. As it should - number of CPUs is not something relevant to parsing
the spec, it's only relevant for building. Of course you *can* end
Also fix some typos and add punctuation.
Follow-up for 44afd5b49c5375dee1892845c2ee873425728138.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2953
-- Commit Summary --
* docs: mention systemd-standalone-sysusers
-- File
Yeah, I think that `SPEC` tag may actually be quite useful for rebuilds. There
are at least two problematic variables in the spec file: the full build paths,
e.g. `cd '/builddir/build/BUILD'`. But if the build is done in mock, the path
is always the same, so this doesn't cause a problem. A secon
Given this .spec file:
~~~rpm-spec
Summary: summary
Name: newpackage
Version: 1
Release: 1%{?dist}
License: MIT
%description
%install
mkdir -p %{buildroot}%{_tmppath}
echo "foo" > %{buildroot}%{_tmppath}/f
%files
%exclude %{_tmppath}/f
%{_tmppath}/f
%changelog
* Tue Jan 16 2024 Vít Ondruch
-
Yup. The reason the warnings are not there yet is that I'm wondering how
meaningful they are in reality, ie does it reach the right audience or will it
be only an annoyance to end users who can't do the damnest thing about it. But
then, nobody will notice a piece of documentation changing.
--
The changes look good. But we need to add the warning right away before this PR
closes #2420
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2948#issuecomment-1985577133
You are receiving this because you are subscribed to this thread.
M
> soft FP is a very rare thing these days, that's the exception that should be
> encoded if at all - I know it's a thing you need to care about on Arm, at
> least in the past, but is it something that needs to be in every single
> dependency, really?
We may need to care about it again with RISC
For a path, maybe this is where we finally introduce `/usr/lib/sysimage` as an
expected path. I could see something like `/usr/lib/sysimage/rpm-config` be a
valid location to store a whole hierarchy of pristine config files.
--
Reply to this email directly or view it on GitHub:
https://github.c
Ostree does something similar, too, maybe we could take a look at that as well:
https://docs.fedoraproject.org/en-US/fedora-silverblue/tips-and-tricks/#_working_with_ostreerpm_ostree
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#
This could also be a potential usecase for FA_REFLINK file-op that's been
tossed around in the PRs.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1985509731
You are receiving this because you are subscribed to this t
For one thing, we need to have a spec for the new format first, and only then
implement it. Using https://github.com/rpm-software-management/rpm/pull/1038 as
a starting point:
- ELF dependencies are tagged with arch information in parentheses after the
main dependency token
- the arch info is f
`static int matches` from `rpmfc.c` implies that rpm provides & requires
generators only run when either `__NAME_magic` or `__NAME_path` is set:
https://github.com/rpm-software-management/rpm/blob/3ad98187cc64a88d2d31d181d10bef5eef6274b7/build/rpmfc.c#L794
Yet, the documentation
https://rpm-sof
It's embarrassing that in this day and age rpm cannot restart an aborted
(crashed, power-cut etc) transaction at all. This requires depsolvers to try
and work around it, while they don't have the necessary details to do so
really. Rpm of course doesn't know where a package originally came from,
17 matches
Mail list logo
