It actually cites the source:
https://github.com/rpm-software-management/rpm/blob/6714ec7068a0343dcb4aaaeb4fe49940c129292f/macros.in#L960
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/721#issuecomment-1811979900
You are receiving
And yeah, the point of those macros is NOT to make it easier to type. They're
there for flexibility.
Those of us who lived through the rise of the multilib will remember fixing a
thousand specs wrt /usr/lib -> %{_libdir} to accommodate for that. And /usr/doc
-> /usr/share/doc change before
Technically, I think we have sufficient APIs nowadays that we could actually
pull file contents such as a changelog from the payload on non-installed
packages. There's some extra cost of course, but just how performance critical
is looking at changelogs? Not very I think.
The "problem" is that
The same tag-query-from-payload thing could be beneficial to various other
cases too, such as RPMTAG_SPEC which could be placed in the payload rather than
the header if we could do this.
--
Reply to this email directly or view it on GitHub:
Closed #2515 as completed via 01fb42d42ca710bf24e3af841d43b4e3d60b3aef.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2515#event-10967022569
You are receiving this because you are subscribed to this thread.
Message ID:
I see %changelog -f as something that would create more issues than it solves,
but like said above, we too would very much like to see better integration with
external changelogs. Let's continue the external changelog discussion in a
dedicated topic:
Closed #393 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/393#event-10966512266
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@dmnks converted this issue into discussion #2767.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/622#event-10965344679
You are receiving this because you are subscribed to this thread.
Message ID:
@dmnks converted this issue into discussion #2765.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/925#event-10965331958
You are receiving this because you are subscribed to this thread.
Message ID:
@dmnks converted this issue into discussion #2766.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/721#event-10965341585
You are receiving this because you are subscribed to this thread.
Message ID:
As stated above we'd rather not have weak/optional BuildDependencies. Having
predictable builds is a value on it's own. Closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/577#issuecomment-1812150848
You are receiving this because
Closed #577 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/577#event-10965418970
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This can probably be done as a plugin nowadays.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1812090168
You are receiving this because you are subscribed to this thread.
Message ID:
With the latest changes to the `%setup` macro this may now be easier and should
be looked at again.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/551#issuecomment-1812148572
You are receiving this because you are subscribed to this
On talk about AI by Tomáš Tomeček I have realized rpm building process it quite
terrible at providing machine processable results for failed builds. I think it
should be reported in machine parseable format, JSON for example.
When the build has failed on BuildRequires: installation, it should
I think rpmbuild should return different return code at least for different
sections, in which the failure occurred. But ideally also with lists of
relevant object types it knows.
--
Reply to this email directly or view it on GitHub:
At least it would be possible to say in which file to search for the error. Not
something the end user has to find himself. Example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=105833248
But in general, I do not think the result should be pure boolean. More likely
something like enum,
I fully support Petr's idea here. It would be amazing to use that data further
in the workflow and display that information nicely in koji, Copr, GitHub,
Gitlab... We could even think about automated retries for certain types of
errors (flakes, network problems) or even fix a spec file if a BR
I don't know what you mean by that. %prep, %build, %install etc are shell
scripts, %files and %changelogs are static data that rpm parses.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2768#discussioncomment-7584794
You are
Can the `%changelog` section being made similar to others, such as `%prep`,
`%build`, etc? Thinking of this, can `%files` section be more similar to those
as well 樂
--
Reply to this email directly or view it on GitHub:
Pretty much all distros have at least the option of pulling the spec changelog
from an external source - namely the package SCM (dist-git in the Fedora
world). There have been various suggestions to make rpm better integrate with
this, such as
-
21 matches
Mail list logo
