Annoyingly the amount of other boilerplate makes this slightly more code
than the original, but then saner code isn't always smaller, and it does
make expandMacros() smaller, which can only be a good thing.
No functional changes.
Handle log level determination inside doOutput() to make the interface
match with the others and as a bonus, make expandMacros() that little
bit smaller again. Empty argument needs to be handled differently
but shouldn't affect functionality.
No functional changes. chkexist and negate arguments are unused for
now, but they could perhaps be used for error condition handling later
(similar to %load)
Replace the "necessary but clunky" string comparisons in expandMacro()
with a lookup on the builtins. For starters, only the primitives
handled in doFoo() are converted, others will require varying amount
of further changes. chkexist argument is unused by doFoo() but will be
needed later for others, add now to avoid having to change more later.
No functional changes intended, anything like that would simply be a bug.
For current uses this shouldn't make any difference, but much of the
macro engine works with string lengths so to avoid having to create
\0-terminated versions of all strings we might look at...
The double-quotes got added in e811c7ec0b
and 2bb7b0cf06 but traditionally there have
been no quotes around %_smp_mflags output, to avoid risking any breakage
due to such a simple thing, lets go back to how it used to be.
There's an increasing number of placing wanting to know the number of
CPU's for parallel processing, and increasingly these things are running
in containers and such where the total host CPU count is not meaningful.
%_lto_cflags can be used to enable LTO (link-time optimization) either
on per-package basis in specs or per-distro basis via %optflags.
Parallel jobs are used automatically where system and configuration
(shared with %_smp_mflags) support it.
Some old v4.0 era packages have RPMTAG_HEADERIMAGE in the signature
header region trailer, instead of the expected RPMTAG_HEADERSIGNATURES.
This was fixed in 4.4.x in commit 21818c6c8f
but regressed in the commit 85a5b00430
refactoring / cleanup.
Reported at https://bugzilla.altlinux.org/show_bug.cgi?id=33710, original
patch by Vladimir D. Seleznev.
It seems that "_LOADED" was replaced by macro LUA_LOADED_TABLE in lua 5.3.4.
Re-establish string "_LOADED" for pre-5.3.4 Lua.
Fixes regression with Lua < 5.3.4 introduced by commit f13de84.
If none of our verify items ranges over the payload, then why bother?
To do this, add an internal rpmvs API to get it's range, and use
that to decide whether trip over the payload is needed or not.
In addition, the payload digest tag needs to be grabbed outside of the
condition to avoid depending on other values. The details including
RPMVSF_NEEDPAYLOAD will be handled internally to rpmvs which makes it
actually nicer code-wise too.
In commit 763d3e44a6 (probably),
headerCheck() started returning rpmvsVerify() return code directly.
But rpmvsVerify() returns 0/1 for success/failure, whereas headerCheck()
is supposed to return an rpmRC where 1 means NOTFOUND, which is
quite a different thing than FAIL. That nobody notices under normal
circumatsnaces
Making headerCheck() return OK/FAIL would be simple, but it's a public
API that used to return NOKEY etc, so perhaps we should try to preserve
that although the only user of headerCheck() I know of is our own rpmdb
code.
So... take the opportunity to do something good and fix it by unifying
the two callbacks which in the end only differ by what they output, so
handle that with a function pointer in the callback data. It's all that
little bit saner this way.
The original file capability verification in rpm incorrectly assumed
empty capabilities equals no capabilities, now we differentiate
between the two and report it in verification. Related to #585.
If a user runs "make check" and then a second user (not root)
runs "make check" the test "FAILED". It is because the test is not
able to create file /tmp/attrtest.cpio because the file is
already there creted by the first user.
1.1^20160101 means 1.1 version (base) and patches which were applied at
that date on top of it.
* 1.1^201601 > 1.1
* 1.1^201601 < 1.1.1
Having symmetry is also good.
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Recommends/Suggests/Supplements/Enhances can also have rich deps,
so we need to extend the check. Or remove it.
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
A digest type unsupported by the underlying crypto library (whether
technically or by configuration) does not mean the digest is invalid,
it just cannot be used. Which for the purposes of verification is the
same as if that digest didn't exist at all, and that's exactly how we
handle digests and signatures disabled by configuration.
One particular case is FIPS mode which globally disables the use of MD5,
which we mishandled prior to this by showing it as OK in verification
despite actually not verifying it at all.
The exact place for handling this case is a bit subtle: the "obvious"
place for checking for supported type is in rpmvsInitRange() but this
doesn't work because of rpmDigestBundleAddID() return code semantics.
The other "obvious" place would be rpmvsVerify(), but by that point
we have even more funny cases to consider. So for now, it's actually
easiest to check for this in rpmvsFiniRange() even if it's not the
most obvious place for doing so. Might want to change the
rpmDigestBundleAddID() semantics later, but this makes for a nicer
backport (we'll need this in 4.14.x too).
In ALT there can be different builds of the same NEVR which only
differ in DistTag, so it is useful to print its value as part of
package information.
Signed-off-by: Vladimir D. Seleznev <vseleznv@altlinux.org>
If a file in a package does not have any capabilities rpm --setcaps should
remove capabilities of the file. Prior to this patch capabilities of the file
were set as empty.
Empty capabilities mean more than no capabilities. A file with no capabilities
can inherit capabilities, but file with empty capabilities can not.
When ever package does not have any capabilities set %|FILECAPS? is false.
If some files have capabilities, %|FILECAPS? is true but %{FILECAPS} is ''
when the file does not have capabilities and '= <capstring>' when there is some.
Reported and patch created by Markus Linnala
Commit message edited by Pavlina Moravcova Varekova and Florian Festi.
Fixes#585Fixes#586
The oldest patch version available from http://ftp.gnu.org/gnu/patch/
is patch 2.5 from August 1997, the same year when commit
636fc4bec9 added support for
"modern patch programs", 21 years ago almost to date. A bit of digging
around reveals that GNU patch 2.1 released in 1993 and patch 2.2 earlier
in 1997. Makes me think perhaps we can risk dropping support for 2.1
without a huge uproar from the community... RIP old fella.
Commit 38c2f6e160 causes --setperms and
--setugids follow symlinks instead of skipping them.
In case of --setperms, all encountered symlinks will have their
target file/directory permissions set to the 0777 of the link itself
(so world writable etc but suid/sgid stripped), temporarily or permanently,
depending on whether the symlink occurs before or after it's target in the
package file list. When the link occurs before its target, there's a short
window where the target is world writable before having it's permissions
reset to original, making it particularly bad for suid/sgid binaries.
--setugids is similarly affected with link targets owner/group changing
to that of the symlink.
Add missing parentheses to the conditions introduced in commit
38c2f6e160 to fix.
Reported by Karel Srot, patch by Pavlina Moravcova Varekova.
Panu Matilainen