Merged #3098 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3098#event-12800386736
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Summary is a mandatory field on rpm packages, we cannot very well write illegal
packages.
If we don't have a meaningful value we need to stick *something* in it.
That said, this is probably a bridge too far and seems easily avoided by
requiring the mandatory base tags to be supplied by the
Yeah I'd prefer a place for ad-hoc tests, because whenever you need to bisect
something you almost certainly want to add it to the test-suite afterwards. So
if it's already in the test format, you just move it around without having to
rewrite from some custom logic.
--
Reply to this email
@pmatilai also suggested that we could have a slot in `rpmlocal.at` reserved
for this that's never checked in.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3097#issuecomment-2109583813
You are receiving this because you are
Move the enablement logic to %__spec_install_template where it can be buried
with relatively little danger of being overridden by distros or packagers.
Its moderately annoying as the logic isnt no longer neatly in one
spot, but %__spec_install_post is commonly overridden by distros and even
We could perhaps have a user-friendly way to do git-bisect with an ad-hoc test
script that's not checked in to the repo, as suggested by @ffesti today.
It seems like `make atshell` (or directly calling `./mktree atshell
`) could be used for this. I'll need to give it a thought or two on
one of
I have used "valid" in a sense that I would not be allowed to create SRPM
without e.g. summary. So apparently, this does not use the same code paths
which is concerning.
Also, when I saw the test case in
Merged #3095 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3095#event-12797198526
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
AIUI the cookie is intended to link packages from a single build together, and
apparently I even documented that: "An opaque value for tracking packages from
a single build operation" So this seems the right thing to do there, not that I
know anybody using the cookie for anything...
--
Reply
One way to make the SRPM "valid" is ofc just adding a dummy description (and
summary, ...). This won't make the difference between the `rpmbuild -bs` and
`rpmbuild -ba` SRPMs go away. Looks like all this dynamic stuff is not very
kind to the SRPMs - the dynamic BuildRequires are similar in
Good to see someone is actually testing these kind of things!
This is kind of intentional. I guess I need to meditate a bit on how
intentional. The Summary being dynamic (aka determined during build) ofc means
it is not available during `rpmbuild -bs`. May be this is just the price to pay
-
11 matches
Mail list logo
