[pacman-dev] Huge cleanup of add.c and my attempt at fixing FS#7484

[Andrew Fyfe]

Dan McGee wrote:
> Ok, I've been slaving away at this for a while and libalpm/add.c is
> finally getting a bit more manageable. Showing a patch is worthless
> because it is huge and is much harder to follow due to the refactoring
> stuff. Instead I've attached a drop-in add.c that compiles cleanly
> with no other changes needed. I'm looking for some feedback on this.
> 
> Some highlights:
> 1. All pactests still pass, so no regressions on that front.
> 2. *Much* cleaner layout. add_commit has now been split across four
> functions (upgrade_remove, extract_single_file, commit_single_pkg, and
> _alpm_add_commit).
> 3. No more super functions. The heaviest function
> (extract_single_file) now weighs in at 350 lines, and a lot of that is
> comments.
> 4. Most of what Andrew started to do in his 7484 patch has been
> brought into this. However, I rewrote it a bit for clarity (at least I
> thought so). We may need a bit more meat added to this section.
> 
> Comments/concerns/questions appreciated. I still want to cleanup the
> huge if(needbackup) section a bit, that is still quite long but hard
> to refactor.
> 
> -Dan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
A HUGE improvement :) The only thing missing is the directory permission 
checks and warning (see the latest patch on my FS7484 branch).

I've got a couple of ideas on how pacman should install a package, your 
break up of add_commit matches up fairly close to what I was planning. 
With the exception of the backup code, I'm thinking that all the 
conflict checks and checks introduced for FS7484 should be done before 
we start adding/removing files from the users system. But this is a post 
3.1 task :)

Andrew