I divided resolvedeps into 2 functions. The new _alpm_resolvedep function will resolve one dependency,
for example the 'foo>=1.0-1' dependency. It can be useful in sync_addtarget refactoring.
The resolvedeps parameters were changed, to be coherent with recursedeps:
* the target-list is an alpm_list* instead of alpm_list**. This is OK, because alpm_list_add == alpm_list_add_last
* syncpkg param was removed. list contains the to-be-installed packages, resolvedeps will add the required dependencies into this list
* trans param was removed, it was used in QUESTION() only, which can be used on the main (handle->trans) transaction only
(because the front-end cannot access our pseudo-transactions at all!)
The patch fixes some wrong dynamic pmdepmissing_t usage.
sync1003.py now fails. This is not a bug, but a behavior change, which needs some explanation:
The old resolvedeps didn't elect packages from 'remove' list. I've dropped this (but can be
reimplemented trivially by adding a 2nd excluding list param to _alpm_resolvedep), because I don't want
that 2nd excluding list param. In fact, in real life, we ~never need this rule. Resolvedeps is called
before checkconflicts, so only -Su's %REPLACES% packages are sitting in 'remove' list. This means, that we have
the replacement packages in our target list. Usually "foo replaces bar" means, that bar isn't in our repos
any more, so resolvedeps *cannot* elect it; but usually it won't try it at all, because foo is in the target
list, and it is expected to satisfy 'bar>=1.0-1'-like dependencies too. In exotic cases this is not true
(like in sync1003.py), then resolvedeps elect bar (new version). Since checkdeps and checkconflicts is done
after resolvedeps, this cannot cause any harm. (In sync1003.py pacman simply removes and reinstalls pkg2 now.)
- for(i = trans->packages; i; i = i->next) {
- pmpkg_t *spkg = ((pmsyncpkg_t *)i->data)->pkg;
- if(_alpm_resolvedeps(db_local, dbs_sync, spkg, &list,
- remove, trans, data) == -1) {
- /* pm_errno is set by resolvedeps */
- ret = -1;
- goto cleanup;
- }
+ if(_alpm_resolvedeps(db_local, dbs_sync, list, remove, data) == -1) {
+ /* pm_errno is set by resolvedeps */
+ ret = -1;
+ goto cleanup;
}
for(i = pulled->next; i; i = i->next) {
--
1.5.6.1
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
07-05-2008, 12:04 AM
Xavier
Resolvedeps rework
Nagy Gabor wrote:
>>From 08ea7d37ae38f26d24ba2d3aba5f7272dee2ab73 Mon Sep 17 00:00:00 2001
> From: Nagy Gabor <ngaba@bibl.u-szeged.hu>
> 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 the 'foo>=1.0-1' dependency. It can be useful in sync_addtarget refactoring.
>
> The resolvedeps parameters were changed, to be coherent with recursedeps:
> * the target-list is an alpm_list* instead of alpm_list**. This is OK, because alpm_list_add == alpm_list_add_last
> * syncpkg param was removed. list contains the to-be-installed packages, resolvedeps will add the required dependencies into this list
> * trans param was removed, it was used in QUESTION() only, which can be used on the main (handle->trans) transaction only
> (because the front-end cannot access our pseudo-transactions at all!)
>
> The patch fixes some wrong dynamic pmdepmissing_t usage.
>
I had a quick reading of the new code, and it looked good to me.
> sync1003.py now fails. This is not a bug, but a behavior change, which needs some explanation:
> The old resolvedeps didn't elect packages from 'remove' list. I've dropped this (but can be
> reimplemented trivially by adding a 2nd excluding list param to _alpm_resolvedep), because I don't want
> that 2nd excluding list param. In fact, in real life, we ~never need this rule. Resolvedeps is called
> before checkconflicts, so only -Su's %REPLACES% packages are sitting in 'remove' list. This means, that we have
> the replacement packages in our target list. Usually "foo replaces bar" means, that bar isn't in our repos
> any more, so resolvedeps *cannot* elect it; but usually it won't try it at all, because foo is in the target
> list, and it is expected to satisfy 'bar>=1.0-1'-like dependencies too. In exotic cases this is not true
> (like in sync1003.py), then resolvedeps elect bar (new version). Since checkdeps and checkconflicts is done
> after resolvedeps, this cannot cause any harm. (In sync1003.py pacman simply removes and reinstalls pkg2 now.)
>
I would suggest just dropping that pactest.
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Hm. This should be _alpm_resolvedep. Shall I resubmit the whole
patch? ;-)
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
07-05-2008, 06:55 PM
Xavier
Resolvedeps rework
Nagy Gabor wrote:
>> +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? ;-)
>
I already pulled these patches on my git repo, without any editing, just
to make it slightly easier for Dan to fetch them.
So I can fix this minor problem, but just a question before I do :
couldn't this function be static, since it is only used inside deps.c
(which is why this error could be easily missed) ?
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
07-05-2008, 07:26 PM
Nagy Gabor
Resolvedeps rework
> Nagy Gabor wrote:
> >> +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? ;-)
> >
>
> I already pulled these patches on my git repo, without any editing,
> just to make it slightly easier for Dan to fetch them.
> So I can fix this minor problem, but just a question before I do :
> couldn't this function be static, since it is only used inside deps.c
> (which is why this error could be easily missed) ?
>
I'd appreciate if you fixed this. This shouldn't be static, since
sync_addtarget rework uses this function (I catched this bug there).
Bye
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
07-05-2008, 07:45 PM
Xavier
Resolvedeps rework
Nagy Gabor wrote:
>
> I'd appreciate if you fixed this. This shouldn't be static, since
> sync_addtarget rework uses this function (I catched this bug there).
>
Oh I see
Fixed there :
http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commitdiff;h=df3901295a6 5b8ec1ad5de6d3545c981ecd0e2ac#patch2
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev