From 2adc17767b1af4e46502f21f5061e19d7a60a4b2 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 10:48:26 +0200
Subject: [PATCH] Remove requiredby from pactests
Also remove some meaningless pactests (broken requiredby, requiredby*.py tests)
requiredby001.py
From 6ef3a1f84dca7559506a6ab4b94b92c4ac746df6 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 11:08:03 +0200
Subject: [PATCH] Modify sync1003.py pactest
Now it tests a more interesting case.
(The old version failed with the new resolvedeps.)
Signed-off-by: Nagy
+pmpkg_t *alpm_resolvedep(pmdepend_t *dep, alpm_list_t *dbs,
alpm_list_t *excluding, pmpkg_t *tpkg);
Hm. This should be _alpm_resolvedep. Shall I resubmit the whole
patch? ;-)
___
pacman-dev mailing list
pacman-dev@archlinux.org
From 6541daa508b3f4d050db61f7212fcedf45ab0120 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 12:53:55 +0200
Subject: [PATCH] sync_addtarget rework
Now '-S provision' handling is done in the back-end.
In case of multiple providers, the first one is selected
From f96b366e8b0e2fb3a74e3647e5e07ecd5b78430e Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 14:55:18 +0200
Subject: [PATCH] Add some verbosity to -S provision and -S group
sync_addtarget rework removed the warning: foo provides bar message
Hi!
Around this -S reworking, I looked into -R foo code, and I noticed
that we search for foo group, THEN literal... This forces pacman to
read all desc files. Wow. pacman -R group is not a common task...
You may say, that I'm cheating, because we will need to check
dependencies which loads the
From d199269813180d4a034fea54d025280aef3e4853 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 4 Jul 2008 15:39:26 +0200
Subject: [PATCH] New _alpm_find_dep_satisfier function
This function finds the first satisfier package in a pkglist.
Using it instead
From 08ea7d37ae38f26d24ba2d3aba5f7272dee2ab73 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 4 Jul 2008 20:18:00 +0200
Subject: [PATCH] Resolvedeps rework
I divided resolvedeps into 2 functions. The new _alpm_resolvedep function will
resolve one dependency,
for example
Now I ran into a problem: The front-end search for _all_ providers
(satisfiers), and will stop if more than one was found. This is not
compatible with resolvedeps behavior... So if we want to keep this, we
cannot share the code (but can re-implement first literal, then
satisfier).
To be more
Maybe you can just drop this behavior for now, because this is indeed
inconsistent with resolvedeps. Then if we want to reintroduce some
kind of handling of multiple satisfiers in the future, it should be
done for both explicit targets (which is currently done in frontend)
and dependency
From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Wed, 2 Jul 2008 17:04:29 +0200
Subject: [PATCH] New sync070.py pactest
This pactest tests the cooperation between front-end and back-end in case of
-S provision operation.
Signed-off
From 0320ac5dabb67813dfe64fddf31a371ec8934126 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 1 Jul 2008 21:06:32 +0200
Subject: [PATCH] Don't duplicate packages in requiredby list
This is a fix for FS#10226.
I think that multiple versioned dependencies are quite common now
From cfe1de25873cf7d3d51a33682286f70e53733c4d Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 1 Jul 2008 22:53:13 +0200
Subject: [PATCH] New _alpm_dep_edge function
The function is introduced to kill some code duplication.
The funcion name uses the 'dependency graph
2008/6/20 Xavier [EMAIL PROTECTED]:
2008/6/20 Nagy Gabor [EMAIL PROTECTED]:
You may trust rpm guys, but don't forget that rpm based distros
usually use different versioning scheme, so '1.0b versus 1.0' is
not a real life example there:
alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora
Yes. And in Xavier's link there is a Problems with Dependencies
paragraph. So it is required to minimize force/epoch in order to
calculate 'foo=1.3-1' dependencies correctly. Question: any foo
package with force will satisfy this. Right?
Wrong. alpm_depcmp uses versioncmp instead of
@@ -861,7 +823,43 @@ int pacman_sync(alpm_list_t *targets)
return(sync_list(sync_dbs, targets));
}
- return(0);
+ if(targets == NULL) {
+ if(config-op_s_sync) {
+ return(0);
I may overlook something, but won't this break -Syu?
From cafa4977a0639ebb30ed20974ad86bf404ca5044 Mon Sep 17 00:00:00 2001
From: Xavier Chantry [EMAIL PROTECTED]
Date: Wed, 28 May 2008 23:25:40 +0200
Subject: [PATCH] Don't display filename on -Qip operation.
Some previous commits apparently broke the get_filename function for
package loaded
2008/6/2 Nagy Gabor [EMAIL PROTECTED]:
@@ -861,7 +823,43 @@ int pacman_sync(alpm_list_t *targets)
return(sync_list(sync_dbs, targets));
}
- return(0);
+ if(targets == NULL) {
+ if(config-op_s_sync) {
+ return(0);
I
Mon, 2 Jun 2008 14:23:49 +0200 -n
Xavier [EMAIL PROTECTED] írta:
On Mon, Jun 2, 2008 at 2:10 PM, Dan McGee [EMAIL PROTECTED] wrote:
On Mon, Jun 2, 2008 at 4:56 AM, Xavier [EMAIL PROTECTED] wrote:
From cafa4977a0639ebb30ed20974ad86bf404ca5044 Mon Sep 17 00:00:00
2001
From: Xavier Chantry
Hi!
This is not a big issue, but memleaks are just ugly.
I mentioned this in the 2. point of my
http://bugs.archlinux.org/task/7884#comment25485 comment.
See pacman/query.c/query_upgrades(): The result of alpm_sync_sysupgrade just
printed but not freed (as I see, the front-end couldn't do it
Add SyncFirst option.
This patch offers a way to fix FS#9228.
By putting SyncFirst = pacman in pacman.conf, the version check will
happen before the transaction really starts, and before any replacements
is
made.
Otherwise, no version check is done.
Idézés Xavier [EMAIL PROTECTED]:
On Mon, May 12, 2008 at 4:00 PM, Dan McGee [EMAIL PROTECTED] wrote:
I thought the same thing- I saw a rewinddir call in db_scan, so I
removed what I thought was an extra one here. Either way, I don't plan
on applying the above patch, as we should just
Hi!
This may be a crazy idea, but I bring this on.
I've read some bugs on bug tracker, and I saw that your kernel is too
old sometimes. The problem is, that many users use custom
kernel (like me), that's why we cannot add 'kernel26=...' dependency
to glibc for example. However, some users
On Mon, May 05, 2008 at 04:40:46PM +0200, Nagy Gabor
[EMAIL PROTECTED] wrote:
old sometimes. The problem is, that many users use custom
kernel (like me), that's why we cannot add 'kernel26=...'
dependency to glibc for example.
s/the problem/your own personal problem/. why pacman would
Xavier wrote:
Well, I already didn't like this script in the first place, I found
the idea ugly.
I still had a look at it to check if it worked. And I see the
implementation is ugly as well, since it's based on -Qi output.
If you take a few steps back, what's happening is so stupid
From f08d8647274fc2c582005f9f0baebc114b2829cd Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 2 May 2008 00:32:45 +0200
Subject: [PATCH] One liner _alpm_pkg_find
This patch kills some code duplication.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
lib/libalpm/package.c
201 - 226 of 226 matches
Mail list logo
