Instead, go the same route we have always taken with version-release in
libalpm and treat it all as one piece of information. Makepkg is the only
script that knows about epoch as a distinct value; from there on out we will
parse out the components as necessary.
This makes the code a lot simpler as far as epoch handling goes. The
downside here is that we are tossing some compatibility to the wind;
packages using force will have to be rebuilt with an incremented epoch to
keep their special status.
Signed-off-by: Dan McGee <dan@archlinux.org>
All functions that are limited to the local translation unit are
declared static. This exposed that the _pkg_get_deltas declaration
in be_local.c was being satified by the function in packages.c which
when declared static caused linker failures.
Fixes all warnings with -Wmissing-{declarations,prototypes}.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
POSIX does not require PATH_MAX be defined when there is not actual
limit to its value. This affects HURD based systems. Work around
this by defining PATH_MAX to 4096 (as on Linux) when this is not
defined.
Also, clean up inclusions of limits.h and remove autoconf check for
this header as we do not use macro shields for its inclusion anyway.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This results in huge gains to a lot of our codepaths since this is the most
frequent method of random access to packages in a list. The gains are seen
in both profiling and real life.
$ pacman -Sii zvbi
real: 0.41 sec -> 0.32 sec
strcmp: 16,669,760 calls -> 473,942 calls
_alpm_pkg_find: 52.73% -> 26.31% of time
$ pacman -Su (no upgrades found)
real: 0.40 sec -> 0.50 sec
strcmp: 19,497,226 calls -> 524,097 calls
_alpm_pkg_find: 52.36% -> 26.15% of time
There is some minor risk with this patch, but most of it should be avoided
by falling back to strcmp() if we encounter a package with a '0' hash value
(which we should not via any existing code path). We also do a strcmp once
hash values match to ensure against hash collisions. The risk left is that a
package name is modified once it was originally set, but the hash value is
left alone. That would probably result in a lot of other problems anyway.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will allow for better control of what was previously the 'force' option
in a PKGBUILD and transferred into the built package.
Signed-off-by: Dan McGee <dan@archlinux.org>
Put the db_operations struct to use and completely split the handling
of the sync and local databases.
Signed-off-by: Allan McRae <allan@archlinux.org>
Cache bullshit only has relevance to be_files, so move it there.
Signed-off-by: Dan McGee <dan@archlinux.org>
[Allan: BIG rebase]
Signed-off-by: Allan McRae <allan@archlinux.org>
Hopefully we've finally arrived at package handling nirvana, or at least
this commit will get us a heck of a lot closer. The former method of getting
the depends list for a package was the following:
1. call alpm_pkg_get_depends()
2. this method would check if the package came from the cache
3. if so, ensure our cache level is correct, otherwise call db_load
4. finally return the depends list
Why did this suck? Because getting the depends list from the package
shouldn't care about whether the package was loaded from a file, from the
'package cache', or some other system which we can't even use because the
damn thing is so complicated. It should just return the depends list.
So what does this commit change? It adds a pointer to a struct of function
pointers to every package for all of these 'package operations' as I've
decided to call them (I know, sounds completely straightforward, right?). So
now when we call an alpm_pkg_get-* function, we don't do any of the cache
logic or anything else there- we let the actual backend handle it by
delegating all work to the method at pkg->ops->get_depends.
Now that be_package has achieved equal status with be_files, we can treat
packages from these completely different load points differently. We know a
package loaded from a zip file will have all of its fields populated, so
we can set up all its accessor functions to be direct accessors. On the
other hand, the packages loaded from the local and sync DBs are not always
fully-loaded, so their accessor functions are routed through the same logic
as before.
Net result? More code. However, this code now make it roughly 52 times
easier to open the door to something like a read-only tar.gz database
backend.
Are you still reading? I'm impressed. Looking at the patch will probably be
clearer than this long-winded explanation.
Signed-off-by: Dan McGee <dan@archlinux.org>
[Allan: rebase and adjust]
Signed-off-by: Allan McRae <allan@archlinux.org>
Implement this seemingly simple change in package.h:
typedef enum _pmpkgfrom_t {
- PKG_FROM_CACHE = 1,
- PKG_FROM_FILE
+ PKG_FROM_FILE = 1,
+ PKG_FROM_LOCALDB,
+ PKG_FROM_SYNCDB
} pmpkgfrom_t;
which requires flushing out several assumptions from around the codebase
with regards to usage of the PKG_FROM_CACHE value. Make some changes where
required to allow the switch, and now the correct value should be set (via a
crude hack) depending on whether a package was loaded as an entry in a local
db or a sync db.
This patch underwent some big rebasing from Allan and Dan.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Move almost all of the caching related stuff into a single #define
(which should maybe even just be a static function) so we don't
duplicate logic all over the place. This also makes the code a heck of a
lot shorter and means further changes to this stuff don't have to touch
each and every getter function.
Signed-off-by: Dan McGee <dan@archlinux.org>
Use strcoll to compare package names to provide output sorted
according to a users LC_COLLATE settings.
Signed-off-by: Andres P <aepd87@gmail.com>
[Allan: added commit message]
Signed-off-by: Allan McRae <allan@archlinux.org>
This will facilitate using this object file on its own in the vercmp tool
which will be done in a future commit. The net impact on the generated
binaries should not be noticeable after this commit.
Signed-off-by: Dan McGee <dan@archlinux.org>
Just as we do in -Qi, we can compute required by information for sync
database packages. The behavior seems sane; for a given package, the -Sii
required by will show all packages in *any* sync database that require it.
Implements FS#16244.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is a bit embarrassing. For example:
$ pacman -Qi mesa
...
Required By : mesa mesa mesa mesa mesa mesa
Something is clearly not right, and the problem was introduced in commit
0bc961. Fix the issue by getting the package name off the correct variable.
Signed-off-by: Dan McGee <dan@archlinux.org>
alpm_pkg_get_name() gives us little benefit in backend code besides a NULL
check on the package passed in; we could do that ourself if necessary. By
changing to direct references in the cases where we are sure we have a valid
package, we save a function call each time we need a package name. This
function can't be inlined because it is externally accessible.
This cuts the calls to get_name() from 1.3 million times in a
pacman -Qu operation to around 2400.
Signed-off-by: Dan McGee <dan@archlinux.org>
After our recent screwup with size_t and ssize_t in the download code, I
found the `-Wsign-conversion` flag to GCC to see if we were doing anything
else boneheaded. I didn't find anything quite as bad, but we did have some
goofups- most of our public unsigned methods would return -1 on error, which
is a bit odd in an unsigned context.
Signed-off-by: Dan McGee <dan@archlinux.org>
This basically started with this change :
/* Transaction */
struct __pmtrans_t {
- pmtranstype_t type;
pmtransflag_t flags;
pmtransstate_t state;
- alpm_list_t *packages; /* list of (pmpkg_t *) */
+ alpm_list_t *add; /* list of (pmpkg_t *) */
+ alpm_list_t *remove; /* list of (pmpkg_t *) */
And then I have to modify all the code accordingly.
This patch utilizes the power of sync.c to fix FS#3492 and FS#5798.
Now an upgrade transaction is just a sync transaction internally (in alpm),
so all sync features are available with -U as well:
* conflict resolving
* sync dependencies from sync repos
* remove unresolvable targets
See http://www.archlinux.org/pipermail/pacman-dev/2009-June/008725.html
for the concept.
We use "mixed" target list, where PKG_FROM_FILE origin indicates local
package file, PKG_FROM_CACHE indicates sync package. The front-end can add
only one type of packages (depending on transaction type) atm, but if alpm
resolves dependencies for -U, we may get a real mixed trans->packages list.
_alpm_pkg_free_trans() was modified so that it can handle both target types
_alpm_add_prepare() was removed, we use _alpm_sync_prepare() instead
_alpm_add_commit() was renamed to _alpm_upgrade_targets()
sync.c (and deps.c) was modified slightly to handle mixed target lists,
the modifications are straightforward. There is one notable change here: We
don't create new upgrade trans in sync.c, we replace the pkgcache entries
with the loaded package files in the target list (this is a bit hackish) and
call _alpm_upgrade_targets(). This implies a TODO (pkg->origin_data.db is
not accessible anymore), but it doesn't hurt anything with pacman front-end,
so it will be fixed later (otherwise this patch would be huge).
I updated the documentation of -U and I added a new pactest, upgrade090.py,
to test the syncdeps feature of -U.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
The main purpose of this function to make our code more readable.
It frees transaction specific fields of pmpkg_t. (It is used when a package
is removed from the target list.)
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
pmsyncpkg_t data sructure was removed:
1. pmpkg_t.reason is used instead of pmsyncpkg_t.newreason. (The target
packages come from sync repos, so we can use this field without any
problems. Upgrade transaction also uses this field to store this info.)
2. pmsyncpkg_t.removes was moved to pmpkg_t.removes.
This step requires careful programming, because we don't duplicate packages
when we add them to trans->packages. So we modify sync pkgcache when we
add this transaction-only info to our package. Hence it is important to
free this list when we remove any package from the target list
(remove_unresolvable, remove_conflicts, trans_free), otherwise this could
confuse the new sync transactions (with non-pacman GUI).
Overall, our code became ~100 line shorter, and we can call our helper
functions directly on trans->packages in sync.c, we don't need to maintain
parallel package lists.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
This function returns with the origin database of a package.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
* Change the return values to be more informative.
It was previously boolean, only indicating if a sync package was newer than
a local package.
Now it is a simple wrapper to vercmp, handling the force flag.
* Remove the verbose output from _alpm_pkg_compare_versions.
The "force" message is not so useful.
The "package : local (v1) is newer than repo (v2)" message can be moved to
-Su operation.
For the -S operation, it is better to have something like :
"downgrading package from v1 to v2"
* Don't display the "up to date -- skipping" and "up to date -- reinstalling"
messages, when the local version is newer than the sync one.
* Fix the behavior of --needed option to not skip a target when the local
version is newer, and clarify its description.
* Add a new alpm_pkg_has_force function
This allows us to access the pkg->force field like any other package fields.
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
The pkg_dup function shouldn't call any alpm_pkg_get_ accessors because
this can fill the old package with all INFRQ_DESC fields for example, and
this won't necessarily be reproduced in the new package (for all the fields
that were copied before).
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
This vercmp issue has been a sticking point but this should resolve many of
the issues that have come up. Only a few minor code changes were necessary
to get the behavior we desired, and this version appears to beat any other
vercmp rendition on a few more cases added in this commit.
This commit passes all 58 vercmp tests currently out there. Other 'fixes'
still fail on a few tests, namely these ones:
test: ver1: 1.5.a ver2: 1.5 ret: -1 expected: 1
==> FAILURE
test: ver1: 1.5 ver2: 1.5.a ret: 1 expected: -1
==> FAILURE
test: ver1: 1.5-1 ver2: 1.5.b ret: 1 expected: -1
==> FAILURE
test: ver1: 1.5.b ver2: 1.5-1 ret: -1 expected: 1
==> FAILURE
4 of 58 tests failed
Signed-off-by: Dan McGee <dan@archlinux.org>
The function is introduced to kill some code duplication. The function name
uses the 'dependency graph' terminology.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is a "fix" for FS#10226. I think that multiple versioned dependencies
are quite common now, and the old behavior is quite annoying there. This
patch won't cause any slow-down.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
We have been using unsigned long as a file size type for a while, which
works but isn't quite correct and could easily break. Worse was probably our
use of int in the download callback functions, which could be restrictive
for packages > 2GB in size.
Switch all file size variables to use off_t, which is the preferred type for
file sizes. Note that at least on Linux, all applications compiled against
libalpm must now be sure to use large file support, where _FILE_OFFSET_BITS
is defined to be 64 or there will be some weird issues that crop up.
Signed-off-by: Dan McGee <dan@archlinux.org>
Commit 8428367285 introduced the regression,
and a previous commit introduced the vercmptest.sh test script to track down
these issues. This commit solves the problem by removing the previous
attempt at locating the pkgrel portions and replacing it with something that
performs the correct logic.
While tracking down everything I needed to, I also found a mistake in one of
the pactests which is fixed here as well as increased the functionality and
verbosity of the vercmptest script to both print out each test it is running
as well as automatically run the mirror of each test case.
Signed-off-by: Dan McGee <dan@archlinux.org>
Actually, just rename _alpm_versioncmp to alpm_pkg_vercmp and get rid of the
need for a wrapper since it did nothing anyway.
Signed-off-by: Dan McGee <dan@archlinux.org>
This code hasn't been looked at in some time. I grabbed a more recent
version of the RPM source (4.4.2.3) and attempted to sync up any changes
they have made, as well as make the libalpm additional code much cleaner and
limited to only a few added lines of code.
The size of this patch might make you think we added code, but bloat-o-meter
actually tells us otherwise:
<function> <old> <new> <diff>
_alpm_versioncmp 1485 1021 -464
Signed-off-by: Dan McGee <dan@archlinux.org>
Any real call of this function doesn't specify a name or version ahead of
time, so just kill that functionality off. Now to remove those dummy
packages...
Signed-off-by: Dan McGee <dan@archlinux.org>
If we have a package without name and/or version, we are really out of luck.
Speed these functions up by removing unnecessary code. Note that both the
splitname and pkg_load functions, where the name and version of packages are
initially populated for databases and pkg.tar.gz files respectively, enforce
that every new package struct created has a name and version.
Signed-off-by: Dan McGee <dan@archlinux.org>
* remove obsolete and unused *_cmp helper functions like deppkg_cmp and
_alpm_grp_cmp
* new alpm_list_remove_str function, used 6 times in handle.c
* remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by
a more general alpm_find_pkg_satisfiers with a cleaner implementation.
before: alpm_db_whatprovides(db, targ)
after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ)
* remove satisfycmp and replace alpm_list_find + satisfycmp usage by
_alpm_find_dep_satisfiers.
before : alpm_list_find(_alpm_db_get_pkgcache(db), dep, satisfycmp)
after : _alpm_find_dep_satisfiers(_alpm_db_get_pkgcache(db), dep)
* remove _alpm_pkgname_pkg_cmp, which was used with alpm_list_remove, and
use _alpm_pkg_find + alpm_list_remove with _alpm_pkg_cmp instead.
This commit actually get rids of all complicated and asymmetric _cmp
functions. I first thought these functions were worth it, be caused it
allowed us to reuse list_find and list_remove. But this was at the detriment
of the clarity and also the ease of use of these functions, dangerous
because of their asymmetricity.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Now the syntax is coherent with alpm_list_find and alpm_sync_find.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
alpm_pkg_load() and parse_descfile() are specific to getting information
from package files, just as other code is specific to getting information
into or out of a package database. Move this code out of package.c, which
should eventually only contain operators on the pmpkg_t struct that do not
depend at all on where the data came from.
Signed-off-by: Dan McGee <dan@archlinux.org>
Reference : FS#9547.
The get_filename function first tries to get the filename field from the
database, and if it doesn't find it, it tries to guess it based on the name,
version and arch.
This field was introduced in 3.0, but there are still many old entries in
the official databases without it. So the databases need to be regenerated
first before this patch can be applied.
There is a second problem with the delta code, which needs the filename for
locally installed packages too, but this field is not present in the local
db. So the delta code needs to be fixed first.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Using the graph structures that Nagy set up for dependency sorting, we now
do a similar process for deltas. Load up all of the deltas into a graph
object on which we can then apply Dijkstra's algorithm, using the new weight
field of graph struct.
We initialize the nodes weight using the base files that we can use in our
filecache (both filename and md5sum must match). The algorithm then picks
the best path among those that can be resolved.
Note that this algorithm has a few advantages over the old one:
1. It is completely file agnostic. These delta chains do not have to consist
of package files- this could be adopted to do delta-fied DBs.
2. It does not use the local_db anymore, or even care if a package or file
is currently installed. Instead, it only looks in the filecache for files
and packages that match delta chain entries.
Original-work-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
