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:
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
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 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:
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
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:
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
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:
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
-
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
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
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
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:
@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 #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:
@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:
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:
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
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
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
21 matches
Mail list logo