Make sure that targeted updates don't do reinstalls
We already had code in add_update_target() to do this, but it did
not cover the multiversion case where more than one package with
the same name is installed.
Bring repodata_lookup_num in sync with repo_lookup_num
It used to return a boolean if the num was found and write
the num over a pointer. This was done because repo_lookup_num
needed to iterate over all repodatas and thus needed to know
if the keyname existed or not.
Nowadays we use repo_lookup_repodata_opt to find the correct
repodata, so we do no longer need the boolean return value.
So we can make repodata_lookup_num work like repo_lookup_num.
This is an INCOMPATIBLE API CHANGE but I'm pretty sure nobody
uses repodate_lookup_num, so this should not hurt anybody.
(You can use a call to repodata_lookup_type to check if the
repodata really contains the num in case the "notfound" value
is returned.)
Change dataiterator, repo_search, and repo_write so that it
uses only the value in the last repodata if multiple repodata
sections have an entry for the keyname.
We do this by first setting up a keyskip array that maps
keynames to a base + repodataid value. We skip a key
if the repodataid does not match the entry in the keyskip
array.
The base is used so that we do not have to clear the array
for the next search. Instead, the base is simply set to a
value greater than all the current entries.
WARNING: As this adds two new elements to the Dataiterator,
this is an INCOMPATIBLE ABI CHANGE. We'll use this to do
a couple of cleanup commits in the next days that have been
postponed until now. We'll bump the soname before doing the
next release.
Change lookup/search code that it returns the match from the last repodata
This is the first part of fixing a longstanding bug. This fixes
the lookup cases and the case where a keyname is provided in the
search/iterator.
We do this by adding a repo_lookup_repodata function that returns the
last repodata that has the specified keyname.
There is also a repo_lookup_repodata_opt function that may return
a repodata that does not contain the keyname instead of NULL. This
is a bit faster if you need to do a lookup anyway.
We also now have a repo_lookup_filelist_repodata that contains all
the logic to deal with filtered filelists.
Add REPOSITORY_FILTEREDFILELIST id and filelist type
REPOSITORY_FILTEREDFILELIST is used to mark that the filelist
in the repodata is filtered with some filter.
The commit also adds a filelisttype element to the repodata
and sets it to filtered if REPOSITORY_FILTEREDFILELIST is set.
It also sets the filelisttype to extension if the repodata
has a filelist and was generated by extending solvables.
We'll use the filelisttype later to decide if we should use
the filtered filelist when searching for files.
Denis Ollier [Thu, 9 Aug 2018 21:05:04 +0000 (23:05 +0200)]
Fix out of bounds compilation warning
When compiling with -D_FORTIFY_SOURCE=2, gcc raises the following
warning:
In file included from /usr/include/string.h:494,
from /build/libsolv/src/libsolv-0.6.35/src/policy.c:16:
In function ‘memcpy’,
inlined from ‘urpm_reorder.isra.18’ at /build/libsolv/src/libsolv-0.6.35/src/policy.c:1239:9:
/usr/include/bits/string_fortified.h:34:10: warning: ‘__builtin_memcpy’ forming offset 8 is out of the bounds [0, 7] [-Warray-bounds]
return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The first memcpy copies 8 bytes whereas the string "kernel" as only 7
bytes. It does not have serious consequence since the second memcpy
overwrites the unwanted byte. Anyway, it is better to fix it.
lastarch is no longer the last element of id2arch, but now the
size of the array. This means that lastarch == 0 now reliable means
that no architecture was set.
To be compatible to old versions we over-allocate id2arch so that
id2arch[lastarch] is always zero.
There's also a new pool_arch2score function that abstracts accessing
the id2arch array.
Dan Nicholson [Thu, 21 Jun 2018 16:51:55 +0000 (11:51 -0500)]
Bump debian control.tar size limit
Increase the arbitrary control.tar limit from 1 MB to 16 MB. We came
across an openjdk-7-jdk package that had a 2.4MB control.tar.gz and
libsolv failed to parse it. dpkg doesn't actually apply a limit to these
files.
Jaroslav Mracek [Tue, 10 Apr 2018 10:47:18 +0000 (12:47 +0200)]
Add const for second variable
The second variable is used as a source for copy and it is not modified
therefore it should be marked as s const. Then it is more easy to identify what
is source and what is target and also it is clear that the source variable will
be not modify by the function.
Additionally it allows to use const map or queue to create a copy or other
operations.