As far as I know, the blocking issue here is simply a decision about where to
get the version of the library. Among others, options include:
1: the rpm version of the package that owns the library. Not a good solution
because I think the maintainers don't want elfdeps to access the RPM DB
> One possible disadvantage: you wouldn't be able to e.g. dnf downgrade xz*
I think it's important to differentiate the real binary dependencies from RPM's
knowledge of those dependencies.
In Fedora 40, it was safe to downgrade xz because libsystemd had been built
before xz 5.6. If it had
That's currently possible and can lead to various subtle runtime failures
instead.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035405478
You are receiving this because you are subscribed to this thread.
Message
One possible disadvantage: you wouldn't be able to e.g. `dnf downgrade xz*`
without also downgrading everything that was built against xz. (You might also
consider that an advantage, but most users probably wouldn't.)
--
Reply to this email directly or view it on GitHub:
> It's arguably package metadata and doesn't belong in the filelist at all if
> possible IMO
Generally, I agree, but I'm operating on the principal that elfdeps shouldn't
access the RPM DB during the build.
(And if we did access the DB for metadata, I'm not sure how we'd allow
packagers to
> The other thing I'm wondering is whether we can (or should) label the
> .elf-version files, so that package managers can skip installing them, the
> same way that documentation is not installed in container images
> (RPMTRANS_FLAG_NODOCS). The .elf-version files aren't needed at runtime,
>
The other thing I'm wondering is whether we can (or should) label the
.elf-version files, so that package managers can skip installing them, the same
way that documentation is not installed in container images
(RPMTRANS_FLAG_NODOCS). The .elf-version files aren't needed at runtime,
they're
> What can happen is that e.g Leap 15.6 with this PR builds an application
> against a library from 15.5 built without this PR. That still needs to be
> installable
/me nods
With the .elf-versions file approach, it would be. The library from 15.5
wouldn't have the .elf-versions file, so any
> In Fedora, packages that fail to build from source are eventually retired
> along with all of their dependencies, and (basically) everything is rebuilt
> for every release, so we wouldn't expect old libraries to mix with new
> applications, there. But if SUSE doesn't retire those packages,
> Is it about using library packages from Leap (old) on Tumbleweed (new)? If
> so, I'd argue that is simply invalid and basically what this approach should
> protect against.
It's not *necessarily* invalid.
In Fedora, packages that fail to build from source are eventually retired along
with
@mlschroe , thoughts on this?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2008964003
You are receiving this because you are subscribed to this thread.
Message ID: ___
> One of the SUSE list members mentioned that they want to continue to be able
> to use LEAP packages as dependencies, and I think this approach addresses
> that concern.
Is it about using library packages from Leap (old) on Tumbleweed (new)? If so,
I'd argue that is simply invalid and
I've added a commit to illustrate a slightly different approach. Code quality
and error handling need more work, and there are no new tests, but I'd like to
ignore that for the moment and discuss only whether this approach is worth
developing further.
This change adds another file to packages
@gordonmessmer pushed 1 commit.
9cb6fc8272970b074e77076369f88a5cacb5c13a Rather than read the version for an
ELF shared object directly
--
View it on GitHub:
> Oh. Yes, I'm subscribed there, so by "other distro folks" I meant non-Fedora
> people
@pmatilai , is there anything I can do to move that conversation forward?
I've written a description of these changes in the form of a design proposal:
@gordonmessmer pushed 1 commit.
3c412b8d2b85112316033bf87746cdfa29542c4d Update path var in tests.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/74450082b087f93c93de752b37cc0b5d5f3b43dd..3c412b8d2b85112316033bf87746cdfa29542c4d
You are receiving this
@gordonmessmer pushed 12 commits.
9450b5fd00be9c53ad4f61dbb7d573ccf372b495 Enhance requires with version
information from the build root.
2ee4efdb819c1011e39d07f0c634e14cd6bfcb7a Provide macros that can be used to
enable fallback version dependencies.
36c3f933da0e974d4ebf4ba015aed77310da299c
I'd been meaning to come back to this quite a while ago, but I got sick and
that put me out for a *long* time.
I still think that *something* should be done with the ELF dep generator, but
more discussion would be helpful.
I mentioned that Debian's approach came up in discussions. On one
@gordonmessmer, this PR seems to have stalled a bit. Do you still wish to have
it reviewed and merged in its current state, or are they changes needed?
In any case, I'll convert it to a draft now as there's some level of
uncertainty around the right approach (based on reading the recent
I get that, and I want to find a way forward that continues to support
compatible library implementations.
Debian's approach is nice in that it allows library packages to indicate an ABI
version that compatible library implementations should also be able to provide,
maintaining their
In general, I'm wary about this whole approach because it reduces/eliminates
the fungibility of compatible library implementations.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1499585799
You are receiving this
(Sorry for the lack of updates for a bit. I've been trying to wrap up a busy
quarter at work.)
I brought this topic up on the [opensuse factory
list](https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/3VB6U6B7RCJL2CDL3X6GNRPQGNO4D6E2/)
where Michal Suchánek brought up
> Are you subscribed to the Fedora devel list?
Oh. Yes, I'm subscribed there, so by "other distro folks" I meant non-Fedora
people :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1453269105
You are receiving
I brought this change up for discussion on the Fedora devel list, and I've made
a couple of changes based on feedback provided there:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/EZFX5ARQWOXBUXID4HH74ETD2QBF2DPB/
--
Reply to this email directly or view it
@gordonmessmer pushed 2 commits.
441504ccb92ddfd4efaa7f07ee73d442fed5da1c Only generate versions when soname is
a symlink to a distinct filename.
e8c984425366463271cb25582804eb4807b5e6bc Use a more accurate name than
"libtool".
--
View it on GitHub:
> At this point I'd be mostly interested in feedback from other distro folks
Are you subscribed to the Fedora devel list?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1438895451
You are receiving this because you are
> I'm pretty sure this breaks the ability to swap between JACK and
> PipeWire-JACK because the soname versioning construct is frozen in
> PipeWire-JACK but regular JACK still gets version bumps.
It looks like it's the other way around, so in this case it's unlikely to be a
problem because
I'm pretty sure this breaks the ability to swap between JACK and PipeWire-JACK
because the soname versioning construct is frozen in PipeWire-JACK but regular
JACK still gets version bumps.
--
Reply to this email directly or view it on GitHub:
Sorry, didn't intend to leave you hanging cold here. At this point I'd be
mostly interested in feedback from other distro folks etc.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1434554612
You are receiving this
Checking in:
Is there anything I can do to help keep this moving forward? Would it be
useful to solicit feedback from a downstream group (e.g. fedora devel@) on
whether this is a usable appoach?
--
Reply to this email directly or view it on GitHub:
Does anyone have any opinions on whether the version needs to be massaged in
any way? Libtool's version system is ... kinda weird. In most cases, we
probably only really care about the leading number, and using the second is
more restrictive than strictly necessary. I'm OK with that, but I
Is everyone happy with the naming of things? Especially the macro and the
command line option?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1426130025
You are receiving this because you are subscribed to this
> there's no requirement to run elfdeps through chroot
OK. I just wanted to be clear that those tests weren't run in chroot for a
reason.
> add a corresponding AT_SKIP_IF() in the tests
Thanks. Tests are conditional now with coverage of both GNU and non-GNU builds.
--
Reply to this email
@gordonmessmer pushed 1 commit.
159dd2d9ddef13c1b7a55b1007007619a62739eb Add tests for the elf dependency
generator fallback version feature.
--
View it on GitHub:
> the tests would need to be conditional on the presence of dlmopen(), but I'm
> not sure how that works in this framework.
You can communicate this kind of a thing to the test-suite via tests/atlocal.in
(the WITH_CAP example probably being most similar to this), and then just add a
We're working to replace fakechroot so that's a (relatively) short-term
concern. And actually there's no requirement to run elfdeps through chroot
(fake or otherwise) because it's a self-contained, non-privileged thing.
Then again, the added tests seem to be working okay as this is passing CI.
Copying the commit message for the tests:
These tests are not compatible with fakechroot, for two reasons.
While fakechroot supports dlmopen(), it will convert relative paths
to absolute paths, which prevents library path searching. The test
could be run from the data directory
@gordonmessmer pushed 1 commit.
8894e4873ec8ab5795aa0ec53a99d8310eff93ce Add tests for the elf dependency
generator fallback version feature.
--
View it on GitHub:
@gordonmessmer pushed 2 commits.
79e769bdf848ede042a055f9513cd56cb7226869 Exit on system failures.
cb8190e9b9f2795fac0e47a916ad2e1d7c7b3a8c Add basic documentation.
--
View it on GitHub:
Any advice or direction for adding tests? I see libhello.so and helloexe in
the testing data... libhello.so could be moved to libhello.so.0.0.1 and
replaced with a symlink, after which elfdeps should provide versioned
dependency information for those objects. Tests would need to be
@gordonmessmer pushed 1 commit.
930c6e99071a0d1121604aa2c5434b09c7d96e9d Exit on system failures.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/fccc4383940987f77c78ff4ade5cd692a2c4cbf3..930c6e99071a0d1121604aa2c5434b09c7d96e9d
You are receiving this
@pmatilai commented on this pull request.
> +destsize = readlink(filename, dest, PATH_MAX);
+if (destsize > 0) {
+ dest[destsize] = 0;
+ filename = dest;
+}
+/*
+ * Start from the end of the string. Verify that it ends with
+ * numbers and dots, preceded by
@pmatilai commented on this pull request.
> + version = getLibtoolVer(linkmap->l_name);
+ }
+ if (version)
+ (void) write(pipefd[1], version, strlen(version));
+ close(pipefd[1]);
+ free(version);
+ dlclose(dl_handle);
+ _exit(0);
+}
@gordonmessmer commented on this pull request.
> + version = getLibtoolVer(linkmap->l_name);
+ }
+ if (version)
+ (void) write(pipefd[1], version, strlen(version));
+ close(pipefd[1]);
+ free(version);
+ dlclose(dl_handle);
+ _exit(0);
+
@gordonmessmer commented on this pull request.
> +destsize = readlink(filename, dest, PATH_MAX);
+if (destsize > 0) {
+ dest[destsize] = 0;
+ filename = dest;
+}
+/*
+ * Start from the end of the string. Verify that it ends with
+ * numbers and dots,
> Should errors encountered during fallback version lookup be a fatal error? It
> sounds like the answer is yes, so I'll make those changes shortly.
Note that even if the generator exists with non-zero, the build does not fail.
https://github.com/rpm-software-management/rpm/issues/1183
--
@pmatilai commented on this pull request.
> + version = getLibtoolVer(linkmap->l_name);
+ }
+ if (version)
+ (void) write(pipefd[1], version, strlen(version));
+ close(pipefd[1]);
+ free(version);
+ dlclose(dl_handle);
+ _exit(0);
+}
@pmatilai commented on this pull request.
> +destsize = readlink(filename, dest, PATH_MAX);
+if (destsize > 0) {
+ dest[destsize] = 0;
+ filename = dest;
+}
+/*
+ * Start from the end of the string. Verify that it ends with
+ * numbers and dots, preceded by
@gordonmessmer pushed 1 commit.
fccc4383940987f77c78ff4ade5cd692a2c4cbf3 Fallback requirements depend on GNU
extensions.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/957efd320451c2f33cfd704e92b13328683f64e6..fccc4383940987f77c78ff4ade5cd692a2c4cbf3
You
Actual errors (IO and the like) should be fatal, yes. Failing to "parse" a
version out of a weird piece, perhaps not, because there are all sorts of weird
ELF constructs out there.
--
Reply to this email directly or view it on GitHub:
> Also check that I/O errors (`EIO`, `ENOMEM`, `ENOSPC`, `EACCES`, `EPERM`,
> etc) result in a non-zero exit code.
*nod*
I'd asked in a code comment because I wasn't sure of the team's preferences, so
I'll ask it here to be really explicit: Should errors encountered during
fallback version
@gordonmessmer pushed 7 commits.
47db768e45187515dff5561dc5f209661d77b52b Enhance requires with version
information from the build root.
87aa2cbee9537bd6d5bad4fb0f713564a0e40706 Provide macros that can be used to
enable fallback version dependencies.
69c4c345772cfd0228562cc224296ea1cd409213
Also check that I/O errors (`EIO`, `ENOMEM`, `ENOSPC`, `EACCES`, `EPERM`, etc)
result in a non-zero exit code.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1419777020
You are receiving this because you are subscribed
@pmatilai commented on this pull request.
> @@ -222,8 +333,17 @@ static void processDynamic(Elf_Scn *scn, GElf_Shdr
> *shdr, elfInfo *ei)
case DT_NEEDED:
if (genRequires(ei)) {
s = elf_strptr(ei->elf, shdr->sh_link, dyn->d_un.d_val);
-
@pmatilai commented on this pull request.
> +if (pipe(pipefd) == -1) {
+ return NULL; // Should this be a fatal error instead?
+}
+cpid = fork();
+if (cpid == -1) {
+ return NULL; // Should this be a fatal error instead?
+}
+if (cpid == 0) {
+ void
@pmatilai commented on this pull request.
> +cpid = fork();
+if (cpid == -1) {
+ return NULL; // Should this be a fatal error instead?
+}
+if (cpid == 0) {
+ void *dl_handle;
+ struct link_map *linkmap;
+ char *version = NULL;
+
+ close(pipefd[0]);
@pmatilai commented on this pull request.
> @@ -542,6 +542,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Use internal dependency generator rather than external helpers?
%_use_internal_dependency_generator1
+#
+# Generate minimum versions for ELF
@gordonmessmer commented on this pull request.
> + * a copy of the version number.
+ */
+static char *getLibtoolVer(const char *filename)
+{
+const char *so;
+char dest[PATH_MAX];
+int destsize = 0;
+int found_digit = 0, found_dot = 0;
+
+destsize = readlink(filename, dest,
@pmatilai commented on this pull request.
> + * a copy of the version number.
+ */
+static char *getLibtoolVer(const char *filename)
+{
+const char *so;
+char dest[PATH_MAX];
+int destsize = 0;
+int found_digit = 0, found_dot = 0;
+
+destsize = readlink(filename, dest,
@pmatilai commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
@gordonmessmer commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
@pmatilai commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
@gordonmessmer commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
@pmatilai commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
The last commit includes macros that can be used to enable the fallback
dependency versions, which are off by default to provide a phased rollout of
the feature.
--
Reply to this email directly or view it on GitHub:
@gordonmessmer pushed 1 commit.
5269fa3d535b9aff3c24509dac97c26bd8364154 Provide macros that can be used to
enable fallback version dependencies.
--
View it on GitHub:
@gordonmessmer pushed 1 commit.
2075c5ea488bb45196c89665f203cf938e63b841 Enhance requires with version
information from the build root.
--
View it on GitHub:
```
$ elfdeps --requires --libtool-version-fallback /lib64/libsoup-3.0.so.0
libz.so.1(ZLIB_1.2.0)(64bit)
libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
@gordonmessmer pushed 1 commit.
0af21b5ca6137983cb0eeea60b1d874302e6f67e Avoid using fallback version when
versioned symbols are found.
--
View it on GitHub:
If we assumed that the SHT_GNU_verneed header appeared before SHT_DYNAMIC, then
when processing the latter, we could loop over the existing ei->requires and
look for elements that start with the same filename, and skip the libtool
version lookup if one is found.
The only problem is that I
```
libgssapi_krb5.so.2()(64bit) >= 2.2
libz.so.1()(64bit) >= 1.2.12
```
Well... almost as intended. Those two are unnecessary since the libraries
provide versioned symbols, and shouldn't have additional version information.
I'll figure out how to detect and skip that case. In the mean time,
This version seems to work as intended. It's more complex than I'd like, but
still probably better than parsing the output of ldd.
```
$ elfdeps --requires --libtool-version-fallback /lib64/libsoup-3.0.so.0
libz.so.1(ZLIB_1.2.0)(64bit)
libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
@gordonmessmer pushed 1 commit.
2ec718ef2f5794c67bdfed8fd915033d472f21e5 Run dlmopen in a child process.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/41da0a2924d11b23a3f8d34efddf2ee39f6b9204..2ec718ef2f5794c67bdfed8fd915033d472f21e5
You are receiving
@gordonmessmer pushed 2 commits.
a01b715f68d025387ea394fa367730e30b9629a2 Enhance requires with version
information from the build root.
41da0a2924d11b23a3f8d34efddf2ee39f6b9204 Resolve symlinks when gathering
libtool version.
--
View it on GitHub:
@gordonmessmer pushed 1 commit.
398827f176a1482fbde837b1b997395d024ff37a Resolve symlinks when gathering
libtool version.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/d0c8fc93976325c931d0a98d1c4ff73581dae8bd..398827f176a1482fbde837b1b997395d024ff37a
You
@gordonmessmer pushed 1 commit.
d0c8fc93976325c931d0a98d1c4ff73581dae8bd Provide an option to use libtool
version in elfdeps.c
--
View it on GitHub:
I've started work on elfdeps.c... It doesn't resolve symlinks to real paths, so
it doesn't get the version number we're actually after yet, and it segfaults if
it calls dlmopen() on libgobject, so that might not be a viable approach to
resolving a dependency to a path. But if anyone wants to
@gordonmessmer pushed 1 commit.
f76936be945f1ef290a92507cb4f322bf719b8ce Provide an option to use libtool
version in elfdeps.c
--
View it on GitHub:
> One thing that comes to mind is that while the Provides: change would be
> backward compatible, the Requires: change would not. New packages would be
> generated with Requirements that existing packages wouldn't satisfy, which
> would require a "rebuild the world" deployment that obsoletes
Ah, I misremembered when it came to where the weakness was. It had to do with
how the Steam Runtime "judges" library versions:
https://github.com/libsdl-org/sdl12-compat/issues/53#issuecomment-979976631
--
Reply to this email directly or view it on GitHub:
> to deal with weaknesses in the Debian's packaging system
I'm curious... do you have a reference that describes those weaknesses? (I
have very little experience with dpkg)
> Bumping the soversion would have been a big deal, since it's an ABI break
I'm not suggesting bumping the major
> > I can think of one real-world case this would have broke: the SDL ->
> > sdl12-compat transition
>
> Would that have required Fedora to do more than either [bump the so
> version](https://github.com/libsdl-org/sdl12-compat/commit/883b629995e998e04b2ccd80a2c3ada46b0ce093)
> or, worst case,
> (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >= 4.8.0)
I'm going to start work on an implementation of this soon. I've been looking
over elfdeps.c and thinking through implementation details, yesterday.
One thing that comes to mind is that while the Provides: change would be
backward
> I can think of one real-world case this would have broke: the SDL ->
> sdl12-compat transition
Would that have required Fedora to do more than either [bump the so
version](https://github.com/libsdl-org/sdl12-compat/commit/883b629995e998e04b2ccd80a2c3ada46b0ce093)
or, worst case, manually add
> > add a versioned requires. (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >=
> > 4.8.0).
>
> The whole point of sonames is that it's NOT tied to versions but the soname
> abstraction, and this kind of dependency breaks that point.
I can think of one real-world case this would have broke:
Oh and BTW, even for a proof-of-concept, you really need to start with the
internal dependency generator. In the external one, the whole world-iview is
upside down, and starting there is likely to run into conceptual problems
elsewhere.
--
Reply to this email directly or view it on GitHub:
Yup, the soname abstraction and the libtool style major.minor.micro version in
the filename don't exactly meet in practise.
So reading through the comments more throroughly, turning the version *in the
filename* (or symlink) into a version as suggested by @keszybz. That'd be
enforcing the
> The whole point of sonames is that it's NOT tied to versions but the soname
> abstraction, and this kind of dependency breaks that point.
I think "the point" is that binaries should not need to re-link when a shared
object is updated with a backward-compatible version.
However, because rpm
> Oh, one more caveat: if the shared library uses symbol versioning, exclude it
> from the new generator.
Understood. This mock-up only applies the externally-enhanced version info to
shared objects that don't provide versioned symbols, and any future work would
do the same.
--
Reply to
> add a versioned requires. (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >=
> 4.8.0).
The whole point of sonames is that it's NOT tied to a particular version, and
this kind of dependency breaks that point.
--
Reply to this email directly or view it on GitHub:
Oh, one more caveat: if the shared library uses symbol versioning, exclude it
from the new generator.
This is important because of at least one important package: `glibc`. Without
this, every build would depend on the latest version of `glibc`. `glibc` spends
a lot of effort making sure that
Looking at the contents of /usr/lib64 on my local system, I see some cases that
look like developers not versioning their so _at all_ (e.g.
libasprintf.so.0.0.0, and 144 others). But that's about 7% of all shared
object files.
Generally: that sounds like it'd be a major improvement, with
A different approach, which wouldn't require calling into `rpm` and dealing
with multiple rpms, would be to:
1. change the existing Provides generator for SONAME to use a version:
`libcurl.so.4()(64bit)` → `libcurl.so.4()(64bit) = 4.8.0`. I think this would
be backwards compatible: because the
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with
@gordonmessmer pushed 1 commit.
c54b9218b9b0aafb643eaa5afdaf490ffb6c1107 Review fixes.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/369bf9b91e5e85f00f7a925e152137598fbed1ba..c54b9218b9b0aafb643eaa5afdaf490ffb6c1107
You are receiving this because you are
> calling rpm from within a generator has always been considered a bad thing to
> do
Understood. I don't think this PR is the _right_ way to solve this problem.
It's just a quick mock-up; I expect to throw it away and do something "the
right way" later.
My hope is that we can discuss
@keszybz commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with %s)\n"
I just want to mention that:
- calling `rpm` from within a generator has always been considered a bad thing
to do
- `rpm -q --whatprovides` may return multiple things -- it might be safer to
`rpm -qf` the actual .so file
--
Reply to this email directly or view it on GitHub:
1 - 100 of 101 matches
Mail list logo
