Moving POPT back into rpm does not imply depriving users of libpopt, but rather
controls for symbol pollution and version mismatches. Do not expose POPT
symbols through rpm libraries.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Moving POPT back into rpm does not imply depriving users of libpopt, but rather
controls for symbol pollution and version mismatches. Do not expose POPT
symbols through rpm libraries.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Running rpmbuild as root, dropping perms through the build, and switching back
to root for installation is neither rocket science, nor "unsolvable"
You claim this should not be in rpm without supplying any reason.
--
You are receiving this because you are subscribed to this thread.
Reply to
You can script up an example using the executable provided with keyutils.
The keyutils API is pleasantly simple.
keyutils is used in RPM5 to save the password passed to gpg for signing as well
as a store for pubkeys: doing an implementation is far simpler than designing
the namespace and going
See issue #496 for a claim that GNOME does indeed embed libpopt still.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
If rpm supplied a simple REPL, exposed in the API, then there would be no need
to reimplement the same REPL stack (usually imperfectly) in multiple
applications, in multiple implementation languages.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
I wonder what this RFE is about. I mean what's the use-case for those
exceptions?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@n3npq that's implementation detail (envvar vs macro).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
If you have patch - please submit PR.
--
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/493#issuecomment-412346540___
Rpm-maint
Closed #468.
--
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/468#event-1784163260___
Rpm-maint mailing list
Closed #461.
--
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/461#event-1784164849___
Rpm-maint mailing list
This is pretty much useless.
Requires: (annobin if gcc) is not same as `Recommends: annobin`. Requires:
annobin sounds a bit better, but not enough.
Solving forward-compatibility is out of scope. CLOSING.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@n3npq if you have patch, please send a PR. This is something what would be
interesting to see.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Other people rely on popt so moving it back to RPM is bad idea. GNOME doesn't
use POPT.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #506.
--
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/506#event-1784160164___
Rpm-maint mailing list
Yes it solves all issues with side-effect macro definitions of tags used
multiple times (like Summary: defining %summary).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpmbuild certainly checks that build dependencies are satisfied before starting
a build (unless disabled), and that check can be done before every link in a
chained build to verify that the just installed previous build does indeed
supply provides that satisfy new build requirements.
I do not
The other impetus for adding exceptions is so the caller can provide a context
(including files and linenos when appropriate) for a failed expansion. Adding a
try...catch wrapper in the rpmbuild parser permits the parser to supply
detailed error information without changing the existing API
As I stated above, I'm interested to see patch and play a bit with it. So if
you have one -- feel free to open PR and I will test it out.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
What's the problem with having one domain? Apart from mo files containing more
than just lib translations.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Do you have patch handy? This would definitely solve some issues.
Also, will it solve issue when %{summary} gets redefined for subpackages?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
For more information, here is the error from config.log, it seems that
something wrong with ld.
```
configure:21692: checking for popt.h
configure:21692: result: yes
configure:21695: checking for poptGetContext in -lpopt
configure:21720: gcc -o conftest -O2 -g -fstack-protector-strong -O2 -g -O2
This sounds useful, although no one requested this in last 6 years as far as I
know. Because all this handled in higher-level tools.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
IMO this should be done in high-level tools (like dnf) instead.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No one has asked for the functionality largely for historical reasons.
Unlike Debian depsolvers, which make heavy use of conflicts to direct an
upgrade including removal of conflicting packages, rpm based depsolvers
typically treat a conflicts as a full stop error, displaying enough information
The general and extensible through configuration method establishes a means to
control for the environment being used by expanding a preamble.
That goes beyond implementation detail into functionality: rpm has always gone
to some lengths to have reproducible builds with scripts that are easy to
Can you supply a usage case or example for needing NEVRA like identifiers while
processing attribute helpers?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
well, you already have `Provides: pkgconfig(foo)`, so we could do something
like `Requires: (pkgconfig(bar) if pkgconfig-static(foo))`. It might be not
perfect, but it is doable even today.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Get a copy of RPM5 rpmio/macro.c (the cvs is browsable at http://rpm5.org even
if the interface is clunky).
Look for "stackarray", the variable that controls the functionality.
There are basically 3 uses:
1) initialize to zero
2) set by parsing/detecting a %{M:S} construct
3) if stackarray is
I can/will point you to the 20-30 lines of code in rpm5 and tell you where to
put them in rpm4 rpmio/macro.c if you wish to "play".
There is too little interest for me to justify the work involved in a PR
however: the functionality has been mentioned before in rpm.org issues in the
past year.
Ok, I think I've got the intent.
The flaw in the approach is that the namespace of pkg-config (and likely
Python/rust/perl/node/Java etc) is very different than rpm package names and a
fully general solution would need to supply mappings between "package"
namespaces that are deliberately using
Your specific example would seem to need a boolean like "contains a static
library" which is more precise than depending on an inference based on a
pattern applied to a conventional package name.
Perhaps a filter of (pattern,envvar-if-true,envvar-if-false) applied to the
file magic strings
> I can/will point you to the 20-30 lines of code in rpm5 and tell you where to
> put them in rpm4 rpmio/macro.c if you wish to "play".
So point me to.
> before in rpm.org issues in the past year
Sorry, you are opening so many of them so I just can't keep up with reading all
of them ;)
--
The existing pkgconfig(...) dependencies in rpm are quite primitive and
awkward, though the mechanism is just cut-n-paste.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The recommended solution in gettext documentation is separate domains for
executables and libraries. This avoids bloat if/when libraries are packaged
separately from executables. The efforts of translation teams are perhaps
simplified by having two smaller domains: the mostly error messages in
@n3npq imagine that you split -devel into -devel + -static packages. My idea
was to add pkg-config file to both packages, but make sure that -devel depends
on Requires stuff while -static depends on both Requires and Requires.private.
There are more use-cases in Python / Rust worlds, but 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/issues/487#issuecomment-412346672___
Rpm-maint mailing list
This sounds interesting, do you have patch to play with?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv have time to look at this?
--
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/462#issuecomment-412347029___
Rpm-maint
the unsolvable problem here is that it won't have necessary permissions to
install RPMs. And this doesn't help because it doesn't know runtime provides
before build. And if it does, it's stupid to build-seewhatcanbebuilt-build-etc.
In any case, this should not be in RPM.
--
You are receiving
Closed #465.
--
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/465#event-1784164042___
Rpm-maint mailing list
@Conan-Kudo you may want to try the new `%_debmacrodir` from debbuild 18.8.1
for your macro bundle.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Delivering an error with rpm --expand '%ifarch' is one usage case for
exceptions that you are surely familiar with since you reported the issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
43 matches
Mail list logo
