So... I was about to ask how come this then works:
```
%{?__debug_package:%{__debug_install_post}}\
%{__arch_install_post}\
%{__os_install_post}\
%{nil}
```
...but the answer is that *it doesn't*. The debug foobar gets appended to
noarch package %install too, contrary to obvious intention of the
Thanks, will tweak the PR accordingly. And yeah, I agree otherwise.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Took more than one night of sleeping over, but here's what I think:
Threading support in general is completely optional, and lack of it doesn't
deprive anybody of any functionality, just a little bit of time. This is stark
contrast to, say, Lua support. So I think we can easily afford to demand
This was kinda ugly-but-necessary when added back in 2003 (commit
752cac72e220dcad4e6fce39508e714e59e3e0a1) but entirely redundant
since the new dependency generator in rpm = 4.9.x with arbitrary
filtering support. The handful of packages using it can just as well
achieve the same (and more)
Having revisited this again, I think I have a better grasp of the whole
mechanism now. And it's way simpler than I originally thought.
First of all, there's no such thing as "support for conditionals inside macro
definitions". Macros are just that - they may contain arbitrary text to be
It would be nice to be able to define which shell should be used with `%()`
given that `/bin/sh` is not the same shell on all distros. Additionally having
to write `$()` macros to the lowest common denominator is just ugly. It's much
nicer to just make _bash_ a `BuildRequires:` and be able to
%_buildshell is for building, %() is macro engine builtin which has no place
following rpmbuild -level macro definitions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Can't you run `%(/usr/bin/bash)`?
--
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/issues/1334#issuecomment-675481660___
Rpm-maint
My understanding is that this should be tied to the `%_buildshell` macro
already.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
So something like a `%_macroshell` would be a better idea, perhaps. But I'm not
sure. I'll need to run a more comprehensive search in the code base first, to
be able to make an educated guess :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@pmatilai good point. That being said, @Conan-Kudo has pointed out that we do
in fact respect `%_buildshell` in other, non-build related areas as well. Doing
a quick grep reveals for example:
`macros.in:%__spec_prep_shell%{___build_shell}`
Still, that doesn't mean we should follow that
> This is not unlike [setting SHELL in
> Makefiles](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html).
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, I deleted that comment after realizing I misunderstood @voxik's question,
but thinking again, it really is not a bad idea at all! It would be easier than
having to redefine `%_macroshell` (or whatever we'd call it) and also cleaner,
as you say. It would also get rid of the problem with
@voxik I can't see why Ruby (or python, or awk, or any other interpreter) would
not work. As for _supported_, that's not my call.
But as you point out, this does allow the spec writer more flexibility in what
interpreter their spec evaluates macros, but does require them to define the
shell
So will Ruby by supported as well? Not that I really care, but what starts
simple might provoke questions like these.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Sure you can. It's worth noting that this RFE is mostly cosmetic; being able to
redefine a macro shell would allow you to replace all the `%(/usr/bin/bash -c
"...")` calls with `%(...)`, as well as avoid spawning a shell just to spawn
another shell.
--
You are receiving this because you are
@voxik That's an interesting idea. You could then do something like `%(ruby:
...)` or `%(python: ...)` or what have you. Sounds cool. Not sure about the
impact of this in a broader sense, but I don't see any reason it couldn't be
done.
That said, doing something just because "we can" doesn't
Oh, I think I misunderstood. As @brianjmurrell said above, any interpreter
would work, yes :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'm yet to understand if there are any security implications by allowing to
redefine the shell in a macro, though. But we already allow that for building
anyway, and building a spec file is no different from running a regular shell
script after all (you should audit the spec file before doing
On Mon, 17 Aug 2020 10:57:59 +0200, Mark Wielaard wrote:
> The commit summary is "Implement DWARF-5", but it mixes that plus
> support for an alternative compiler and debug-types in one commit.
> Would it be possible to split this in 3 patches, one for basic DWARF-5
> support, one for testing
diff --git a/ci/Dockerfile b/ci/Dockerfile
index d8b0115bd..2e872be5f 100644
--- a/ci/Dockerfile
+++ b/ci/Dockerfile
@@ -45,6 +45,7 @@ RUN dnf -y install \
pkgconfig \
/usr/bin/gdb-add-index \
dwz \
+ clang llvm \
&& dnf clean all
COPY . .
diff --git a/tests/debugedit.at
diff --git a/tests/debugedit.at b/tests/debugedit.at
index 49721a342..bcd86ac67 100644
--- a/tests/debugedit.at
+++ b/tests/debugedit.at
@@ -253,9 +253,8 @@ AT_CLEANUP
# ===
# Make sure -fdebug-types-section has updated strings in objects.
# ===
-AT_SETUP([debugedit .debug_types objects])
diff --git a/tools/debugedit.c b/tools/debugedit.c
index c2884933c..8e85847d1 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -233,7 +233,7 @@ typedef struct
int shift = 0; \
do \
{ \
-
To be used by next DWARF-5 patch.
diff --git a/tools/debugedit.c b/tools/debugedit.c
index ff72759ca..9f1dc2d3f 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -1457,37 +1457,128 @@ edit_dwarf2_line (DSO *dso)
}
}
-/* Called during phase zero for each debug_line table referenced
diff --git a/tools/debugedit.c b/tools/debugedit.c
index 8e85847d1..ff72759ca 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -1155,7 +1155,7 @@ get_line_table (DSO *dso, size_t off, struct line_table
**table)
if (lines->table[i].old_idx == off)
{
*table =
@Conan-Kudo approved this pull request.
--
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/1333#pullrequestreview-469937196___
Making everything configurable is not such a hot idea, really. Making the shell
macro configurable means you open up the possibility of anybody screwing up the
core macro primitive. %() equals popen() which means system shell, whatever
that is, and I believe that should be left alone.
--
You
27 matches
Mail list logo
