In case of error some allocated memory wasn't freed in commit_single_pkg.
Note: The return value of this function is not used.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
The dynamic pmconflict_t must be freed with _alpm_conflict_free.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
Errors like the following one happen regularly (for unknown reasons...) :
error: could not open file /var/lib/pacman/local//glibc-2.7-9/depends: No
such file or directory
Anyway, every time an user reported an error like that, it always seemed
like he thought the error was caused by the double /, which is obviously
wrong.
Since db->path always include a trailing /, there is no need to add one when
concatenating paths in be_files.c or add.c.
Additionally, some static strings were switched to dynamic.
And the computation of the "dbpath"/"pkgname"-"pkgversion" was refactored
in db_read, db_write and db_remove with a get_pkgpath static function.
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
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>
This event was unused, was missing the equivalent EXTRACT_DONE event, and
was useless because we already have ADD / UPGRADE START and DONE events.
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
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>
* 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>
We only need a copy of this string once we know we are going to extract it,
and we don't need a static buffer to copy it into since it is coming from a
known-length string.
Signed-off-by: Dan McGee <dan@archlinux.org>
We were a bit juryrigged using one call to mkstemp() before rather than
extracting the new files side-by-side and doing our comparisons there. We
were also facing some permissions issues. Instead, make our life easier by
extracting all temp files to a '.paccheck' extension, doing our md5
comparisons, and then taking the correct actions.
Still to be done here- a cleanup of the use of PATH_MAX which should not be
necessary if we use dynamic allocation on the heap.
Signed-off-by: Dan McGee <dan@archlinux.org>
I'm not sure why these were ever here, as by this point we have already
extracted the file meaning a call to this function is basically a no-op.
Signed-off-by: Dan McGee <dan@archlinux.org>
Things must have gotten stricter with GCC 4.3 on the '%zd' printf string and
this is the first I've tried to compile there. Fix the problem by using
size_t instead of int.
Signed-off-by: Dan McGee <dan@archlinux.org>
There were a few issues with this code:
1. We already had an open fd to a file, but never used it to our benefit.
Use the libarchive convienence method to write the current file contents
straight to a file descriptor.
2. The real problem cropped up on Windows where the locking semantics caused
the old way of extraction to fail because we had an open file descriptor.
By using the file descriptor and closing it ASAP, we prevent these
failures.
Signed-off-by: Dan McGee <dan@archlinux.org>
After the libarchive upgrade from 2.4.12 to 2.4.14, our usage of
archive_entry_pathname became dangerous. We were using the result of that
function even after calls to archive_entry_set_pathname.
With 2.4.14, the entryname becomes wrong after these calls, and so all the
future use of entryname are bogus. entryname is used quite a lot for
logging, so that's not so bad. But it's also used for the backup handling,
so that's not very cool. For example, reinstalling a package with backup
entries will erase all the md5 entries from the DB, because they won't be
found back.
entryname is now a static string so that we can easily keep the result of
archive_entry_pathname.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
[Dan: fixed version numbers in commit message]
Signed-off-by: Dan McGee <dan@archlinux.org>
The _alpm_backup_split function always alloced memory for the fname, and we
let it disappear in a specific case (upgrade026.py). Fix the issue.
Signed-off-by: Dan McGee <dan@archlinux.org>
Its implementation was quite broken:
* add_loadtarget() might have silently filtered out some targets when
replacing an older version.
* This was used in sync.c to determine whether a target is implicit or not,
which is incorrect behavior. Before this patch we silently removed user
confirmed replacements; now we always warn on a replacement.
* remove001.py behavior was quite odd in adding same target 5 times to the
target list, we can change this behavior to be a failure.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
[Xav: changed remove001 pactest accordingly]
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
[Dan: rewrote commit message]
Signed-off-by: Dan McGee <dan@archlinux.org>
Fixes FS#9235.
We already had the following case in extract_single_file :
/* cases 1,2,3: couldn't stat an existing file, skip all backup checks */
But we actually only did a lstat here. And if lstat worked, we did a stat
without checking.
When lstat works and stat fails, it means we have a broken symlink, like in
FS#9235. We can actually treat this case like a non-existing file.
The broken symlink will then be simply overwritten.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
This is the symmetric of --asdeps, install packages explicitly.
Documentation and completion files were updated accordingly.
Added sync301.py and upgrade032.py pactest files to test this.
I also made a little modification in ALLDEPS handling too.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
This also affects all structures with static strings, such as depmiss,
conflict, etc. This should help a lot with memory usage, and hopefully make
things a bit more "idiot proof".
Currently our pactest pass/fail rate is identical before and after this
patch. This is not to say it is a perfect patch- I have yet to pull valgrind
out. However, this should be quite safe to use in all situations from here
on out, and we can start plugging the memleaks.
Original-work-by: Aaron Griffin <aaronmgriffin@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
This was the case of the bash packaging error where a file was removed from
the package but not the backup array.
I just added a sanity check so that only the files from the backup array
that are also in the filelist are used.
I had to edit upgrade026 pactest slightly : it required the file to be
copied to .pacsave instead of moved. But just moving it should be enough, as
we agreed on the ML :
http://www.archlinux.org/pipermail/pacman-dev/2007-December/010440.html
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is the bash case when the /etc/profile file was removed by error from
the package, but stayed in the backup array.
Ref:
http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003556.html
Also fixed a little typo in add.c, but it's disabled code.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
As I mentioned earlier on the ML :
http://www.archlinux.org/pipermail/pacman-dev/2007-December/010416.html
the first part of commit 843d368ef6 had no effect because of a bug.
So I fixed the bug, but since this would change backup handling behavior,
and possibly require other bigger changes to work right, I decided to just
disable that part temporarily, and left a TODO in the code.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Update the GPL boilerplate to direct people to the GNU website for a copy of
the license, as well as bump all of Judd's copyrights to 2007.
Signed-off-by: Dan McGee <dan@archlinux.org>
alpm_list_find and alpm_list_find_ptr will now return a void *, and
alpm_list_find_str will return a char *, instead of an int.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
I started playing around with gcov today and it showed a few places in the
code that we don't test at all. This is the start of ensuring that we
execute most of the code in our codebase.
Signed-off-by: Dan McGee <dan@archlinux.org>
_alpm_innerconflicts: check for target<->target conflicts
_alpm_outerconflicts: check for target<->localpkg conflicts
This will be useful in sync.c clean-up and in testdb.c
As an application the patch also fixes a misleading message (and a memleak)
in add.c
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
checkdeps and resolvedeps now take both a remove list and an install list as
arguments, allowing dependencies to be calculated correctly.
This broke the sync990 pactest, but this pactest used dependencies and
provides in an unusual way, so it has been changed.
Dan: the sync990 pactest was just plain wrong. It didn't satisfy the
dependencies correctly, so should never have succeeded.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
[Dan: some variable renaming, clarification in commit message]
Signed-off-by: Dan McGee <dan@archlinux.org>
This operation made sense in the days before sync DBs existed, but it no
longer has the same usefulness it once did.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Aaron Griffin <aaronmgriffin@gmail.com>
pmdepmissing_t was used for two totally different things :
missing dependencies, and dependency conflicts.
So this patch simply adds a type for dep conflicts,
and convert the code to use it.
This fix the TODO in conflict.c :
/* TODO WTF is a 'depmissing' doing indicating a conflict? */
Additionally, the code in conflict.c now eliminates the duplicated conflicts.
If pkg1 conflicts with pkg2, and pkg2 conflicts with pkg1, only one of them will be stored.
However the conflict handling in sync_prepare (sync.c) is still very asymetrical, and very ugly too.
This should be improved in the future (there is already a pending patch from Nagy that cleans it a lot).
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
The names related to conflicts are misleading :
For dependencies conflicts, the type is pmdepmissing,
and the function names contain just "conflict".
For file conflicts, the type is pmconflict,
and some functions contained just "conflict", some others "fileconflict".
So this is the first step for improving the situation.
Original idea/patch from Nagy, but the patch already didn't apply anymore,
so I did it again.
The main difference is that I kept the conflictype, with the following renaming :
pmconflicttype_t -> pmfileconflicttype_t
PM_CONFLICT_TYPE_TARGET -> PM_FILECONFLICT_TARGET
PM_CONFLICT_TYPE_FILE -> PM_FILECONFLICT_FILESYSTEM
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
This file only contained one private function : _alpm_db_whatprovides .
And the public alpm_db_whatprovides was in db.c , so I moved everything there.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
[Dan: updated POTFILES.in as well]
Signed-off-by: Dan McGee <dan@archlinux.org>
The old alpm_list_find was renamed to alpm_list_find_ptr, and a new
alpm_list_find was introduced, which uses the fn comparison-function
parameter in its decision.
Now both alpm_list_find_ptr (a new ptrcmp helper function was also
added) and alpm_list_find_str are just an alpm_list_find call.
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
[Dan: made ptrcmp a static function]
Signed-off-by: Dan McGee <dan@archlinux.org>
Instead of using the often-busted REQUIREDBY entries in the pacman database,
compute them each time they are required. This should help many things:
1. Simplify the codebase
2. Prevent future database corruption
3. Ensure when we do use requiredby, it is always correct
4. Shrink the pmpkg_t memory overhead
Signed-off-by: Dan McGee <dan@archlinux.org>
Linux lstat follows POSIX standards and dereferences a symlink pointing
to a directory if there is a trailing slash. For purposes of libalpm, we
don't want this so make a lstat wrapper that suppresses this behavior.
Signed-off-by: Dan McGee <dan@archlinux.org>
I broke scriptlet logging with ad691001e2.
Readd more or less what was there before, although it still needs a lot of
work including hopefully rewriting it to a new event subsystem and having
it log to a seperate file.
Signed-off-by: Dan McGee <dan@archlinux.org>
Packages and DBs now support using the UNIX epoch (seconds since Jan 1, 1970)
for use in builddate and installdate. This will only affect newly built
packages. Old existing packages with the text format are still supported, but
this is deprecated.
In the case of removal of text time support, this code will fail gracefully,
returning the start of the epoch for broken packages.
Signed-off-by: Aaron Griffin <aaronmgriffin@gmail.com>
