About my pending work on http://code.toofishes.net/cgit/xavier/pacman.git/

parseargs: sent to the ML and updated according to feedback

depwork: forgot if I send this stuff, should I ?

pactree: all the work I did with Dave Reisner on pactree C rewrite,
all ready and done now. depends on depwork for find_satisfier

sodeps: depends on parseargs because it changes one arg, and on
depwork (make depcmp private), because it changes many _alpm_depcmp to
_alpm_depcmp_tolerant. This was sent to ML. Nagy said it was ok. I
find this distinction between depcmp (ignore -Sdd) vs depcmp_tolerant
(respect -Sdd) a bit ugly, but I don't see any better way.

I am happy with parseargs, depwork, and pactree.

One small worry about depwork and its alpm_find_satisfier function :
the purpose of this function is kinda duplicated with "alpm/dep: add
alpm_find_dbs_satisfier" I made in working.
After writing alpm_find_dbs_satisfier, I thought I would kill
alpm_find_satisfier, but both have different advantages, and slightly
different purpose.

alpm_find_satisfier is very simple : it just calls
splitdep+_alpm_find_dep_satisfier, which are both very simple. It just
answers this question : is there one satisfier for this dep in this
package list ? Perfect for deptest / pacman -T, could be useful for
other tools.

alpm_find_dbs_satisfier: much more complex, but similar purpose. its
goal is to answer : which satisfier would pacman choose for this dep
in this list of sync dbs ? Less flexible than alpm_find_satisfier
(cannot give any list of package, it has to be one or more db), much
uglier and complex code. But it exposes exactly what pacman does to
find a satisfier :
- search literal in a first pass, provider in a second pass only if no literal
- for both pass, it scans the list of sync dbs in order, and the first
sync db has priority over the next ones
- handles ignorepkg with a QUESTION IgnorePkg callback (but this can
be disabled simply with no or empty conversation callback)
- handle multiple provision with another QUESTION callback, but same
as for ignorepkg

I needed alpm_find_dbs_satisfier to migrate pacman frontend to the
alpm_add_pkg(pmpkg_t *) interface. I decided to keep
alpm_find_satisfier anyway for its simplicity.

For the stuff on working, I probably need other mails to present it.

On 20/10/10 04:39, Xavier Chantry wrote:

About my pending work on http://code.toofishes.net/cgit/xavier/pacman.git/

parseargs: sent to the ML and updated according to feedback


I like how the sorting that has been implemented now. Ack.


depwork: forgot if I send this stuff, should I ?


Never seen it before, but looking at the patches now I give it an ack.


pactree: all the work I did with Dave Reisner on pactree C rewrite,
all ready and done now. depends on depwork for find_satisfier


Cool. Still not sure about moving it to util instead of contrib. It
does not really fit in with vercmp, testdb etc which are distributed by
"make install".



sodeps: depends on parseargs because it changes one arg, and on
depwork (make depcmp private), because it changes many _alpm_depcmp to
_alpm_depcmp_tolerant. This was sent to ML. Nagy said it was ok. I
find this distinction between depcmp (ignore -Sdd) vs depcmp_tolerant
(respect -Sdd) a bit ugly, but I don't see any better way.


No comment from me - I have not had time to look at these in detail.


Allan

On Wed, Oct 20, 2010 at 6:54 AM, Allan McRae <allan@archlinux.org> wrote:
>> pactree: all the work I did with Dave Reisner on pactree C rewrite,
>> all ready and done now. depends on depwork for find_satisfier
>
> Cool. *Still not sure about moving it to util instead of contrib. *It does
> not really fit in with vercmp, testdb etc which are distributed by "make
> install".
>

It was more a technical than a logical separation.
It was easy to add pactree C in src/util next to all the other alpm
based C programs.

1) it helps to look at the existing C standalone progs to start a new one
2) the Makefile / .gitignore is easy to extend

These two arguments probably apply to having scripts in contrib/ directory.

I don't know how to best deal with this technical separation and the
more logical one (utils shipped by make install vs contrib stuff).

On 20/10/10 04:39, Xavier Chantry wrote:

About my pending work on http://code.toofishes.net/cgit/xavier/pacman.git/


I have pulled the following branches of Xavier's onto my working branch:
- clang
- depwork
- pactree
- parseargs

I am not sure what the decision was (if any) with your epoch branches so
I have left them at the moment.


As far as your working branch goes, I will comment elsewhere on the
selection dialog in the relevant thread.


Allan

On 20.10.2010 06:54, Allan McRae wrote:
> On 20/10/10 04:39, Xavier Chantry wrote:
>> About my pending work on http://code.toofishes.net/cgit/xavier/pacman.git/
>>
>> sodeps: depends on parseargs because it changes one arg, and on
>> depwork (make depcmp private), because it changes many _alpm_depcmp to
>> _alpm_depcmp_tolerant. This was sent to ML. Nagy said it was ok. I
>> find this distinction between depcmp (ignore -Sdd) vs depcmp_tolerant
>> (respect -Sdd) a bit ugly, but I don't see any better way.
>
> No comment from me - I have not had time to look at these in detail.

Just bumping this againso it doesn't get lost.


--
Florian Pritz -- {flo,bluewind}@server-speed.net