Thank you for pointing out where the test for --nomanifest is performed.
I do suggest that all the code in rpminstall.c is in need of simplification for
clarity.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://githu
Again my bad: you are correct that the symbol cannot be linked.
What is surprising to me is that there is no longer any obvious low level API
to read rpm package sections provided in the API.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vi
Closed #513.
--
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/513#event-1792518590___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Loader maps instead of RPM_GNUC_INTERNAL might have some advantages maintaining
an ABI: everything is collected in one location, and a naming discipline (like
"rpm*") with exceptions becomes easier to focus on.
Meanwhile retrofitting an ABI that is maintainable onto old code is painful,
thankle
While assessing whether I should submit a patch to simplify rpminstall.c to use
an rpmgi argument iterator, I find that it is no longer possible to query a
package on the network.
The intent of the refactoring in rpminstall.c and rpmgi.c clearly indicates a
desire to remove rpmio from rpm entir
Entirely equivalent to the scheme above, and perhaps more general, is a glibc
RFE for the ability to attach an opaque vector to a FILE * fp. The scheme
originally outlined could possibly be done without any significant change to
glibc internals: the ability to retrieve an opaque pointer from an
The COPYING file -- such as it has always been -- specifies dual licensing for
code in lib/*.
This leaves the license subject to interpretation, and a strict reading would
render code in build/* or rpmio/* only available under GPL.
A looser reading, keeping in mind the intent was to permit othe
Recent issues -- the pending PR for speeding up rpm kernel builds and the
addition of fsync come to mind -- lead me to ask up front:
What approaches to speeding up rpm installs are deemed acceptable?
The techniques (event loop and/or threads and/or coroutines etc etc) are very
well known.
But
Hello. I'm hitting the following warning(several times) while compiling
firefox.spec (from `dnf download --source firefox`) using command `$ time
rpmbuild -bb -v -- ~/rpmbuild/SPECS/firefox.spec`:
Warning, not replacing comp_dir
'/home/user/rpmbuild/BUILD/firefox-61.0.2/objdir/media/ffvpx/libav
