Merged #813 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/813#event-2556717466___
Rpm-maint mailing list
pmatilai commented on this pull request.
> @@ -65,6 +65,7 @@ EXTRA_DIST += data/SPECS/symlinktest.spec
EXTRA_DIST += data/SPECS/deptest.spec
EXTRA_DIST += data/SPECS/verifyscript.spec
EXTRA_DIST += data/SPECS/fakeshell.spec
+EXTRA_DIST += data/SPECS/mini.spec
So it seems...
--
You are
ignatenkobrain commented on this pull request.
> @@ -65,6 +65,7 @@ EXTRA_DIST += data/SPECS/symlinktest.spec
EXTRA_DIST += data/SPECS/deptest.spec
EXTRA_DIST += data/SPECS/verifyscript.spec
EXTRA_DIST += data/SPECS/fakeshell.spec
+EXTRA_DIST += data/SPECS/mini.spec
didn't you forgot to
More ripples from the parseLines() unification, the callers used to
explicitly allocate an empty string buffer, but with lazy allocation
from parseLines() they're getting NULL in the special circumstance of
being last in the spec, and no "body". Specifically this happens with
empty %description or
Closed #815.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/815#event-2556286671___
Rpm-maint mailing list
I would probably prefer `add`/`remove` combination, which would be more work on
one side, but IMHO better then "replace by nothing" to remove flag.
But I like the idea.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Um, rpm macros have nothing to do with m4.
I don't have any concrete proposals at this time, just asking for a rethink and
pointing to the general direction that I would find acceptable.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
> I'm really reluctant to add one-trick-pony utility macros like this because
> over time they tend to become liabilities one way or the other, and have
> other issues.
Good.
>
> Manipulating compiler flags is a very common need indeed and could use some
> help from rpm, but that need is not
Thx for the reference. I'd still appreciate some improvement here, because the
behavior is confusing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'm really reluctant to add one-trick-pony utility macros like this because
over time they tend to become liabilities one way or the other, and have other
issues.
Manipulating compiler flags is a very common need indeed and could use some
help from rpm, but that need is not limited to
@marxin Why is this necessary?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/815#issuecomment-521185369___
Rpm-maint mailing
Note that %_lto_cflags is not in any released rpm version yet, only 4.15
alpha/beta have had it. So this is just about the last minute to drop it
without concerns about breaking stuff.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
The macro function is intended for %{optflags} manipulation
(replacement, conditional addition).
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/815
-- Commit Summary --
* Come up with replace_optflags (#814).
-- File
13 matches
Mail list logo
