Re: [pacman-dev] some pacman work
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.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
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
participants (3)
-
Allan McRae
-
Florian Pritz
-
Xavier Chantry