The problem with adding an option do disable it is precisely that it would then
be possible to disable it. As in, a feature you cannot rely on is a rather
broken feature.
Compressing the parsed spec would be quite reasonable, but we lack a general
mechanism to compress/uncompress header tag
Plugins aren't executed from within the chroot, and they can't be because some
of their (or RPM's own) dependencies (selinux in this case) may not be
installed there.
What we could do perhaps is to use the selinux policy of the target root but
whether that's doable remains to be seen (I'm
I can't reproduce this myself but it does look suspicious. However, assuming
that you did *not* make any changes to the RPM sources before running the
tests, this suggests that the order in which the file iterator internally
serves file entries is undefined, and just happens to order them in
Note that whatever the solution, DNF would need to be updated accordingly
(probably the `--installroot` logic).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2623#issuecomment-1768243702
You are receiving this because you are
Thanks. I wonder if the `--macros` option (or its API equivalent in
`include/rpm/rpmmacro.h`) could be used then? The little downside is that the
caller would have to list all the default paths themselves (just with the
target root prefix). Maybe we could improve that somehow and facilitate
This sounds like a problem of package *distribution*, not package building.
As I understand it, your actual goal here is to avoid *shipping* a subpackage
in the repositories. The current "workaround" as you described it therefore is
the proper solution to this.
The contents of the buildroot is
