> Yeah, known. Missing/wrong arguments to built-in macros are wildly
> inconsistent in how they behave, some emit errors, some just fail silently
> etc.
Evidently better way is to emit an error.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Seems we should get rid of AM_PATH_LIBGCRYPT ;(
--
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/pull/826#issuecomment-526559914___
- in a majority of examples in manual the text after the --queryformat
argument is in double quotes - thus it does not look good to wrote
that A query format is passed to RPM after the --queryformat
argument, and normally should be enclosed in single quotes.
- in case of:
rpm -qa -i
> * The expansion of macro %{getmem:virt}" finishes with an error. It is
> because getmem returns 0. This is caused by the fact that function
> getmem_virt returns SIZE_MAX. After dividing by 1024^2 it is still to high to
> fit into return_type of getmem (unsigned int).
Right. I probably
I tested this PR on my laptop.
- The expansion of macro %{getmem:virt}" finishes with an error. It is because
getmem returns 0. This is caused by the fact that function getmem_virt returns
SIZE_MAX. After dividing by 1024^2 it is still to high to fit into return_type
of getmem (unsigned int).
Choice is good ;)
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/826
-- Commit Summary --
* Support libgrypt as crypto library
-- File Changes --
M configure.ac (16)
M rpmio/Makefile.am (6)
A
Yeah, a behavior change this big would've needed to be in the alpha already,
because it's bound to break a bunch of creative macros here and there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, traditionally --install is not allowed to erase anything, which (to me at
least) makes sense most of the time. But like you note, with --replacepkgs the
old header will be removed no matter what, so an erase element does seem a sane
thing to do. It's a behavior change that might cause
I guess fixing this is too late for 4.15.0?
--
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/313#issuecomment-526517883___
It's trivial to change the code to also add an erase element for --install if
the NEVRA is the same. (It's actually also what libsolv expects). I didn't do
it because I read in some old thread that you don't like erases with 'rpm
--install'. (The old header will get replaced anyway, so an erase
Just for the record, this also fixes the case where a package with
self-conflict fails with -Uvh --replacepkgs style reinstall
(https://bugzilla.redhat.com/show_bug.cgi?id=1693212)
As expected it doesn't deal with -ivh --replacepkgs in the same case (of
self-conflicts), which is a rather
11 matches
Mail list logo
