@praiskup It is exactly the same problem. We will continue to have these issues
at the distribution level until we change the way we model how a package
exports an interface e.g. list of shared objects. There is perhaps a broader
question that this mistake would *not* have been caught without
@pmatilai I agree that while a "search path" is a fundamental part of the model
for the full view of the dynamic loader, it need not be pat of rpm's `elfdeps`
and could become some kind of filter option that is driven by libc specific
search information.
--
Reply to this email directly or
@pmatilai Just for clarity we are leaving out `DT_RPATH`, environmental
combination of `LD_LIBRARY_PATH` and the search paths (packages that alter
shell defaults and global search paths), `LD_PRELOAD` interposition (similar to
`LD_LIBRARY_PATH` but early loads the SONAME), and `DT_RUNPATH` and
@pmatilai I realize that my suggestion looks a lot like what you were
attempting to do on a per-package basis? Were you trying to (a) create a
template /etc/ld.so.conf which just includes the the fragment directory, and
for the buildroot of the rpm build (b) allow it to parse any fragments that
When we talk about 1464368 I assume we mean
https://bugzilla.redhat.com/show_bug.cgi?id=1464368
@praiskup When you say "tooling" I expect that between us we need to decide
what we need and why we need it (to document the reason for the feature). Is
there a specific tool you wish you had? What
@pmatilai Can you expand a bit on what you mean by not liking parsing other
people's config files? Is it that you would like a clean way to discover the
system library paths searched by the dynamic loader?
--
Reply to this email directly or view it on GitHub:
@pmatilai Thanks for the reference Panu. I'm deeply involved in glibc, so I
won't have time to get back to this, but I thought I'd take a stab at a problem
I saw as inherently structural that could be resolved in an incremental fashion
without an external API change. Overhauling the entire
@n3npq Just as an example I added line numbers to the warnings in
https://github.com/rpm-software-management/rpm/pull/494 so you can see what I'm
thinking about and how to extend the existing interface to a new one with
minimal change. Then have the spec file parser use the new interface. The
The macro expansion API lacks location information for warnings.
The simplest way to add this information is to pass location
information to a new macro expansion API and for that location
to be used in subsequence diagonistics.
A new 'struct rpmSpecLocation_s' structure is created to hold the
@n3npq What are the restrictions on changing external interfaces like this? Are
the structures and APIs frozen forever and backwards compatible?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@n3npq Thanks for the pointers about %trace and %dump. In the end they would
not be needed if there was source and line information ;-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
While developing glibc.spec for Fedora I ran into this issue:
fedpkg srpm
warning: Macro %glibc needs whitespace before body
warning: Macro %glibc needs whitespace before body
Wrote: /mnt/ssd/carlos/fedsrc/glibc-rawhide/glibc-2.28-3.fc29.src.rpm
This was caused by the following line:
1243 #
12 matches
Mail list logo
